search

lyarenei / jellyfin-plugin-listenbrainz

ListenBrainz plugin for Jellyfin.
MIT License
65 stars 2 forks source link

[Request]: Save a permanent local copy of listening history #88

Open UnviableFriend opened 4 months ago

UnviableFriend commented 4 months ago

Description

Save a permanent local copy of listens (Optionally?).

Proposed solution

Even a JSON file per user would work well, I think. My listens are largely imported from last.fm, so there isn't as many details in them, but my 350k+ downloaded listen data from LB only uses 304MB. So space shouldn't really be a big concern.

Additional context

There was a small period where LB was offline the day before this issue was made, and in the past there has been issues that have resulted in a loss of some listens. Things like this are likely to happen despite how hard the devs work to keep everything working smoothly. Additionally a person may lose their account info, or delete their account, or listen history, for one reason or another and want a way to recover it later. A local realtime backup of listens would give peace of mind and simplify recovery of data if the need arises.

lyarenei commented 4 months ago

There was a small period where LB was offline the day before this issue was made, and in the past there has been issues that have resulted in a loss of some listens. Things like this are likely to happen despite how hard the devs work to keep everything working smoothly.

This is exactly what the listen cache feature is for - if the listen submissions fail, then they are saved and resubmitted later. Unfortunately, this was broken among other things in the version 3.4.0.0 (#87) so I get where are you coming from.

Additionally a person may lose their account info, or delete their account, or listen history, for one reason or another and want a way to recover it later.

I believe this is more on the user than anything. All of these situations are ultimately the reason why one should regularly back up their data, especially if it holds some significance for them. The user can always export their listens and feedbacks.

A local realtime backup of listens would give peace of mind and simplify recovery of data if the need arises.

Although this is a bit nitpicky, you could argue that you can lose the access to the server as well (unless you are not running Jellyfin locally on your network). But other than that, I think some sort of tracking has been probably already done by some external monitoring tools. Back when I used Plex, I also used Tautulli and it tracked everything, provided graphs and so on, it was really nice. I'm not sure, but I wouldn't be surprised if someone already did similar tool for Jellyfin.

On the other hand, if you wanted to keep it simple, then probably a Jellyfin plugin entirely dedicated to that would be the way to go. Maybe the playback reporting plugin could fit the use-case?

With the plugin approach, there is also an issue with data storage location where you would usually save the json file. Basically when you upgrade plugin, the plugin data folder changes (the plugin version is a part of the folder name) and so you would have your activity history all over place. Of course this can be worked around by just having the file elsewhere, but that's not a good practice. You also need to track the file and make sure it's deleted when the plugin is uninstalled where with the plugin data directory, the whole folder just gets deleted. You could send data to somewhere else, but that just increases complexity.

TL;DR, unless I am missing something, this is something where a separate plugin would make more sense. Especially as natural next step for such plugin would be to track all activity, not just music playback. Assuming there isn't an already existing solution which would do the job.

Let me know what you think.

UnviableFriend commented 4 months ago

There was "the incident" as an example of times where this would be especially helpful. A local copy in the same format as it's being submitted would be very easy to grab data from any time frame that was lost on servers and resubmit. That could also be helped by users backing up their data, but I doubt most know they can, let alone would remember to do it regularly(Figuring out how to automate mine is on my todo list).

That said, I guess it could be a better feature request to have playback reporting implement export features(I think currently it can only do a full backup of everything?)

lyarenei commented 4 months ago

There was "the incident" as an example of times where this would be especially helpful.

Ah, I see. I didn't even know about that tbh. But yeah, if ListenBrainz has to do a DB restore, then the user backup is the only option to get back the data.

A local copy in the same format as it's being submitted would be very easy to grab data from any time frame that was lost on servers and resubmit. That could also be helped by users backing up their data, but I doubt most know they can, let alone would remember to do it regularly(Figuring out how to automate mine is on my todo list).

That said, I guess it could be a better feature request to have playback reporting implement export features(I think currently it can only do a full backup of everything?)

Hmm, I think I might have misunderstood what you meant at first. I thought that you meant some sort of generic playback history keeping (and I was focused on the generic part a bit too much), which is something that does not fit into this plugin very well - and that's why I suggested the playback reporting plugin.

But if reword this into let's say automatic ListenBrainz data backup, then it sounds much nicer (to me).

Some implementation notes: