@coral hound lets take the conversation here instead of spamming the general channel
#album artists sort
modest meteor
modest meteor
So, it appears we have another tag that isnt parsed by ffmpeg/ffprobe then
coral hound
Yep. I seem to have a knack for finding them!
modest meteor
We could extend that other id3 tag reader perhaps then
coral hound
To be fair, I suspect it's also that classical music tends to have a few more of these corner cases
Ironically, one of the things that drove me away from using Plex for my music library!
I guess we have to generalise this:
modest meteor
Well, the good thing is that you can now have influence over it to optimize it
coral hound
Yep, Plex's direction is... not this...
I'll have a think how to make the eyed3 section a bit more generalised so we can put anything else in that ffprobe doesn't pick up.
Need to have a look at what eye3d's view of the file is as well
modest meteor
Also note that the outcome may differ between filetypes. ffmpeg behaves better on flac files
coral hound
Yep
I haven't got any flac files to test it on at the moment (all ripped in mp3 for the time being)
Equally, the behaviour should be fairly simple, to only try and overwrite if a tag hasn't already been set via ffmpeg
coral hound
Not sure that eyed3 actually reads the albumartistsort tag either: https://eyed3.readthedocs.io/en/latest/_modules/eyed3/id3/tag.html?highlight=eyed3.tag
Actually, I might be reading that wrongly - can you access all tags via the dictionary, or only the ones mapped to properties
coral hound
Seems not. Would there be any prospect of switching to Mutagen as the fallback, rather than eyed3. That definitely seems to be able to read all tags, and given that it's what Picard uses, that would ensure compatibility
modest meteor
If we do that, we probbaly need to switch to mutagen completely. And Mutagen adds some complexity. In the past I had some horrible experiences with it so I so much liked the fact that we could keep it with ffmpeg. I guess we already stepped of that path my introducing eyed3.
The difference is that eyed3 is pure python and mutagen is a C library so a little bit more difficult with building etc. so it might hurt at once point with newer python versions etc.
So if we are going through the whole troubles of switching to mutagen, I think it would be best to completely switch it over as mutagen is the most complete tag library
coral hound
Yeah
I have no particular horse in the race myself
Definitely a chunk of work to migrate to a different library though
Equally, not a massive fan of try library A, then try library B etc
(in code)
modest meteor
Exactly - so either we get it to work now with ffmpeg + eyed3 or we convert it all into mutagen and do it right
I'm pretty sure that eyed3 will read the tag btw - did you inspect the data in the debugger ?
coral hound
No, not yet
I just couldn't see where in the eyed3 api you can read arbitrary tags
Didn't get as far as working up an example.
coral hound
Was thinking, for the time being, I could presumably just create an nfo file to fill in the blanks?
modest meteor
Was thinking, for the time being, I could presumably just create an nfo file to ...
Yes, that will work
coral hound
Robust enough for the time being, and avoids the complication of a complete rewrite of the tagging system for now. I suspect we may have to/want to do that at some point in the future, but feels like there are probably other priorities
coral hound
Yep, works as a reasonable workaround: (Carlos was originally under 'C' for similar reasons to Herbert)
I'll amend the docs with the known issue when I have a minute. Not a perfect solution (nothing ever is!) but at least avoids spending time rewriting the whole tag parser at the moment for a corner case
modest meteor
I think rewriting it is not a super big deal but there is no perfect tag reader. They all have their own issues
coral hound
Yep. I still suspect we have more work to do there at some point. I'd like to wrap it many more automated tests before undertaking anything though, and that depends on me having enough time!
It may well be that we wind up with a wide variety of methods for pulling tags and that it just has to systematically try options when it encounters an issue.
modest meteor
It may well be that we wind up with a wide variety of methods for pulling tags a...
Could be - I also want to increase the speed at some point by scanning multiple folders at once. Now we do folder per folder and file for file which is super safe but slow as &^%&^&^
coral hound
Yeah - there's almost certainly some improvements to be had in the scan speed
Or, more to the point, scan time
While playing around with this to try and pin it down, I've also got the feeling that the UI around rescanning etc isn't ideal - it often gets into a slightly cached state where I have to refresh the page
modest meteor
why is that not ideal ? it makes perfect sense that the frontend is cached
otherwise we are overloading the server with calls