How to reload metadata for music files?

[DonMacaroni 54]

So, I fixed tons of mistyped casings in Artist names and hit refresh metadata afterwards, but in Emby nothing changed. It still shows previous information. Is there any way to force Emby to reload info from ID3v2 tags? So far I have only managed to do it, via removing actual files/folders physically and adding them back, but it is kind of annoying way to do it.

Edited November 29, 2024 by DonMacaroni

[Luke 42077]

Hi there, can you please provide a specific example? Thanks.

[DonMacaroni 54]

I had an album, in folder media/singles/Arhard & Anub1s - Don't Blame Me
Changed tag fields ARTIST and ALBUMARTIST and made Arhard Uppercase as ARHARD, also changed filepath to capital letters, so it became ARHARD & Anub1s - Don't Blame Me
After that, refreshed rescanned library files and Emby added it as "new", but...in metadata it kept the old lowercase version of ARTITS and ALBUMARTIST fiields and no matter what I do, it persists that. Only way to fix it is to delete whole folder from library drive and add it back, then Emby thinks it is completely new and re-reads those filed values.

 

 

embyserver.txt

Edited November 29, 2024 by DonMacaroni

[DonMacaroni 54]

Why it does not refresh it is beyond me as per logs, it even removed it from DB and added back.
I have also noticed such behaviour earlier, but this time it started to annoy me more as I did bunch of other similar changes as well and to get these to display in Emby, basically would mean nuking the library and rescanning everything as these are single files all over the place.

Edited November 29, 2024 by DonMacaroni

[user24 313]

Hi, AFAIK (and according to Luke???), there are some instances with case-changes, and certain character types, e.g. apostrophes/inverted commas "" versus '' and brackets [] versus (), where Emby accepts the first use-case into the database and then always uses this whenever there are small inconsistencies in other original data of the same name.

There are at least two previous threads on this relating to Genres:

https://emby.media/community/index.php?/topic/130230-case-changes-in-genres-using-mp3tag-wont-update/#comment-1368521

https://emby.media/community/index.php?/topic/45767-two-genres-for-the-price-of-one/page/2/#comment-431024

As I mentioned in the more recent thread, I also tried Genre, Album, Artist and Album Artist with similar results.

This is great if the first-use-instance is the correct one that you always want to revert to, but not so great if you ever want to change the first-use-instance and all subsequent ones. I think I managed to get around the problem (for me) by updating tags in Mp3tag and then updating the same info again within the relevant Emby fields so that source files and Emby data match each other. It's a bit of frustrating double handling, but perhaps better than nuking a library?!?! Sorry, I don't know of an easier way.

As music is mostly based on embedded metadata, my preference would be for Emby to always go by the embedded metadata, even if there are inconsistencies that then need to be fixed in the source files.

Edited November 29, 2024 by user24

[DonMacaroni 54]

Yeah updating manually works as well, but this is what I would like to avoid. I have already spent too much time and effort curating my library with Mp3tag and have proper tags on everything. As my library is quite big and dates back multiple decades, I still find some inconsistencies from time to time which I tend to fix and then it is quite annoying that Emby simply ignores it and I need to jump through flaming loops to get it to accept the change as well. 

Edited November 29, 2024 by DonMacaroni

[user24 313]

Yes, I understand exactly, having a decades-old 100k+ track music library created across many different systems and methods! Even if my music tag info is 90% correct, there are likely still 10k+ errors or omissions that are being found every now and again that I want to correct as I find them.

Once a good workflow is determined e.g. update in Mp3tag (perhaps add missing MusicBrainz info) and then recan in Emby to import the changes, then ideally that method should work consistently.

I guess Emby is catering more to the casual-user, rather than the power-user, so ignoring case-changes could therefore make sense for the majority and the Emby business?

It would be nice though, if details such as this were in the official Emby documentation, so it would be easy to find and better understand rather than going through the frustration of trying multiple ways and searching the forum for sometimes vague answers.

[DonMacaroni 54]

Another great hidden feature...

Basically, if you reorganize your library folders, rescan...all your playlists are nuked. Playlists themselves remain, but contents are wiped out so they are pretty much empty m3u files.

Now question remains, how to restore these?
Is they backed up somewhere? Are they are maybe retrievable from database?

Because this is pretty effed up situation I have ended up with, I could update (now broken) paths myself but everything is gone.
I definitely need to recover these, somehow

I have Server Backup plugin and it takes daily backups, but playlists files are empty in backups as well. 

Edited December 6, 2024 by DonMacaroni

[Happy2Play 9780]

14 minutes ago, DonMacaroni said:

Another great hidden feature...

Basically, if you reorganize your library folders, rescan...all your playlists are nuked. Playlists themselves remain, but contents are wiped out so they are pretty much empty m3u files.

Now question remains, how to restore these?
Is they backed up somewhere? Are they are maybe retrievable from database?

Because this is pretty effed up situation I have ended up with, I could update (now broken) paths myself but everything is gone.
I definitely need to recover these, somehow

I have Server Backup plugin and it takes daily backups, but playlists files are empty in backups as well. 

If you don't have a backup that contained the original location, then the playlist is lost and has to be recreated.

@Lukethis may be something that need to just break/error out instead of nuking the playlist when path to media no longer exists.  As currently once playlist is cleared there is no way restore, and odds are remembering everything in playlist can be slim. 

So users can at least go to m3u and update media paths.

[DonMacaroni 54]

Quote

If you don't have a backup that contained the original location, then the playlist is lost and has to be recreated.

To my understanding I had backups, made by backup plugin, I keep 7 days.
But when I look at those, only embyserver-backup-full has those files and they are empty there as well.

I did that change 3 days ago, so at least past 4 day backups should have them, but all those only contain *.db files.

Yes, they could be re-created, but there were tens of it, some were spawned by my wife and she would be really pissed now.
Also you really expect user to remember all those hundreds of files, out of ten thousands which they may have curated to playlists? 

[DonMacaroni 54]

I can personally probably retrieve these from BTRFS filesystem snapshots (I keep 52, versioned ones, oldest is 1y), but users with Ext4 or if snapshots not enabled (by default they are not) are completely out of luck.

Quote

this may be something that need to just break/error out instead of nuking the playlist when path to media no longer exists.  As currently once playlist is cleared there is no way restore, and odds are remembering everything in playlist can be slim. 

@LukeIMHO, it would make sense to keep these as they are, with broken paths and error out with playback attempt. Then it is up to user to decide, if he wants to delete these, re-add files, update paths manually, etc...

Currently, as all the placeholders remained, I was pretty sure, that they are all intact and paths just need to be updated if anything at all, until I actually opened one.

 

EDIT: Restored from BTRFS snapshots, updated paths and copied back into subfolders overwriting empty ones, in:

/var/packages/EmbyServer/var/data/userplaylists/

Refreshed metadata (in playlists, otherwise they remained blank in Emby) and everything is back to normal.

Still it was not something I expected to happen as most other software, either leaves you with broken playlists or updates paths during rescan. Especially since those playlists were created with Emby itself.

Edited December 6, 2024 by DonMacaroni
Update

[Happy2Play 9780]

19 minutes ago, DonMacaroni said:

so at least past 4 day backups should have them, but all those only contain *.db files.

Make sure you copy at least on out so daily backups don't delete them all.

Not positive but since you can query the id in the api you should be able to manually extract the info from a old db but will probably need dev assistance here

 

 

Also note there is only one full backup and all other backups only contain previous db. 

So it may be beneficial to have your own system backup plan on Emby Programdata folder.

Data path: /var/packages/EmbyServer/var

As full backups can be slow and problematic also as in my case the Emby Programdata folder is about 60Gb one reason Emby only maintains ONE full backup.

So if someone does not save with media this folder will balloon a lot larger.

Edited December 6, 2024 by Happy2Play

[DonMacaroni 54]

This is what I actually have BTRFS snapshots for, it is way easier to restore something which was accidentally deleted/modified from (hourly) snapshot, then restoring something from backups, either local or even worse offsite one. Application folders don't have snapshots, but home(s) folders have it enabled and as "embyserver-backup-full" gets written into dedicated Emby user home folder (which I, yet again, spawned myself, system users do not have home folder by default in DSM), I could grab these from those. Thing is, nothing of it exists by default for regular (Synology) user, so I was kind of shocked for a moment and managed to write here, before I managed to think about my options and disaster recovery plans.

Edited December 6, 2024 by DonMacaroni

[Happy2Play 9780]

1 minute ago, DonMacaroni said:

This is what I actually have BTRFS snapshots for, it is way easier to restore something which was accidentally deleted/modified from (hourly) snapshot, then restoring something from backups, either local or even worse offsite one. Application folders don't have snapshots, but home(s) folders have it enabled and as "embyserver-backup-full" gets written into dedicated Emby user home folder (which I, yet again, spawned myself, system users do not have home folder by default in DSM), I could grab these from those.

Yes you will most likely have to do that, manually update paths in the playlist then copy the content back into the existing Empty playlist m3u files as they will still have all the linked userdatashares in the database.

[DonMacaroni 54]

Quote

Yes you will most likely have to do that, manually update paths in the playlist then copy the content back into the existing Empty playlist m3u files as they will still have all the linked userdatashares in the database.

Already did, only trick was that you had to click "refresh metadata" on all of playlists, to get content re-appear in Emby. But not everyone has BTRFS snapshots enabled (performance hit, space constraints, etc.) or are familiar with Linux commandline to copy files around from shell.

[Luke 42077]

1 hour ago, DonMacaroni said:

Another great hidden feature...

Basically, if you reorganize your library folders, rescan...all your playlists are nuked. Playlists themselves remain, but contents are wiped out so they are pretty much empty m3u files.

Now question remains, how to restore these?
Is they backed up somewhere? Are they are maybe retrievable from database?

Because this is pretty effed up situation I have ended up with, I could update (now broken) paths myself but everything is gone.
I definitely need to recover these, somehow

I have Server Backup plugin and it takes daily backups, but playlists files are empty in backups as well. 

Hi, what you can do is edit the m3u files and then run a library scan after that. That should bring the content back.

[DonMacaroni 54]

1 minute ago, Luke said:

Hi, what you can do is edit the m3u files and then run a library scan after that. That should bring the content back.

m3u files were empty, except file header, I checked with vi. Only way to restore these, were to grab these via other means, in my case filesystem snapshot.

Edited December 6, 2024 by DonMacaroni

[Happy2Play 9780]

2 minutes ago, Luke said:

Hi, what you can do is edit the m3u files and then run a library scan after that. That should bring the content back.

But this assume you know all the content that was in the now empty file. 

Bad data needs to remain so it can be edited.

[DonMacaroni 54]

This is how they all looked for me:

#EXTM3U
#PLAYLIST:Remakes

And that was the all the content they had, just header, containing playlist name. Everything else was blank.

Edited December 6, 2024 by DonMacaroni

[Carlo 4561]

I've never liked having playlists stored this way.  Collections used to be this way before as well and it to would cause problems when content was moved on the file system.

Having the playlist items removed from playlists when content is moved in libraries is actually a pretty big problem that needs some kind change to stop all the playlist items from vanishing when it's highly likely there may not be a backup.

What I'd suggest is a small change in logic.  Do not remove these items from the playlist if the media is missing from the library.
Only remove the item from a playlist if a manual delete of media is done through the interface by an authorized user.
This isn't without it's issue as a playlist with error out if played with a missing item but it's IMHO it's still better to have a faulty playlist with info in it them an empty one that doesn't play either.   This would at least allow an admin to search/replace paths or manually update the playlist files if needed.

I don't really see a downside to adapting to this approach, all things considered.