Album Tag Importer

[GrimReaper 4913]

53 minutes ago, user24 said:

Agree, now that I have tried it. I'm happy to revert back to your order. The GUI looks better in your original order. I just need to get used to the process

Let me think about that one a bit. I should have something workable this afternoon (CET time), as I'm AFAIK for the better part of today. 

[user24 365]

6 minutes ago, GrimReaper said:

If you want, I can apply same logic to RELEASETYPE

Aaahhh - that explains it -  I was testing both RELEASETYPE and ROONALBUMTAG as if they were both multi-field. Now, from your explanation, it makes sense with the errors I was getting. Yes, normal use-case for me would be only one RELEASETYPE as a standard entity and various ROONALBUMTAG tags to suit anything and everything non-standard. So your usability assumption was correct. But, it may(?) be better if both had the same logic. (Reason - MusicBrainz release types system which I may want to use in the future - because I may be able to map them into  "omnibus"  tags???) 

I need to try some mapping experiments - I have an idea - but it will take a while to test it properly.

11 minutes ago, GrimReaper said:

I should have something workable this afternoon

No hurry at all - I need at least a full day uninterrupted to try the mapping... which will likely be tomorrow now...

[GrimReaper 4913]

The more complex the code introduced, the more likely it is some unexpected/unintended results will occur down the line.

That said:

v0.8

- Complete GUI overhaul (you won't be able to skip over Import Mode now )

emby_album_tag_importer.py

Edited Saturday at 01:13 PM by GrimReaper

[GrimReaper 4913]

GUI was getting overwhelmed with all the stuff crammed in, needed some breathing room.

v0.9

- GUI reworked

 

emby_album_tag_importer.py

Edited Saturday at 06:40 PM by GrimReaper

[GrimReaper 4913]

v1.0
- MUSICBRAINZ_ALBUMTYPE tag support added
- Export Log function added

emby_album_tag_importer.py

Edited yesterday at 01:46 AM by GrimReaper

[user24 365]

V1.0 RELEASETYPE Mapping test...

Using Importer - Bulk Cleared all Album Tags in Emby (45 "The Beatles" Albums) - extremely easy and fast to do

Using Mp3tag - rewrote all RELEASETYPE tags as short single descriptors (somewhat similar to MusicBrainz):

Using Importer - mapped these tags to "omnibus" tags:

(first go at this - no problems)

Using custom Group By - all Albums appeared in their relevant groups in Emby:

Note: Doing this manually in Emby, one Album at a time, (e.g.) 1min per Album = 45min. With Importer - probably 5min max!!!

Then, tried a scenario where I change my mind and want to split Soundtracks away from Compilations...

Using Mp3tag - not required now, as Albums have single descriptors already.

Using Importer - remap the tags:

Using custom Group By - these Albums then appeared in their new groups in Emby:

Time taken - perhaps 1-2min???

Only problem was I could not figure out how to "Save mappings". Clicking this did nothing. Clicking "Load mappings" opens up a window to access saved files - but I had nothing previously saved to try. Closing Importer and opening again (didn't shut down PC) retains the previous mapping settings. Perhaps I am missing a step in the process somewhere?

I'll give it another go later on... plenty of other combinations and permutations to try...

This is going to be SO EASY to properly 'album tag' my whole library and import into Emby now!

Edited yesterday at 04:03 AM by user24

[GrimReaper 4913]

4 hours ago, user24 said:

V1.0 RELEASETYPE Mapping test...

Using Importer - Bulk Cleared all Album Tags in Emby (45 "The Beatles" Albums) - extremely easy and fast to do

Using Mp3tag - rewrote all RELEASETYPE tags as short single descriptors (somewhat similar to MusicBrainz):

Using Importer - mapped these tags to "omnibus" tags:

(first go at this - no problems)

Using custom Group By - all Albums appeared in their relevant groups in Emby:

Note: Doing this manually in Emby, one Album at a time, (e.g.) 1min per Album = 45min. With Importer - probably 5min max!!!

Then, tried a scenario where I change my mind and want to split Soundtracks away from Compilations...

Using Mp3tag - not required now, as Albums have single descriptors already.

Using Importer - remap the tags:

Using custom Group By - these Albums then appeared in their new groups in Emby:

Time taken - perhaps 1-2min???

Thanks for extensive testing, glad it's working with no apparent issues.  

4 hours ago, user24 said:

Only problem was I could not figure out how to "Save mappings". Clicking this did nothing. Clicking "Load mappings" opens up a window to access saved files - but I had nothing previously saved to try. Closing Importer and opening again (didn't shut down PC) retains the previous mapping settings. Perhaps I am missing a step in the process somewhere?

Mappings are always saved into the small helper file (mappings.json) in the same folder as the script; the file is shared between RT and ROON mapping sessions. Pressing Save just writes the current mapping rows into it. If you want, I could call a file picker on Save, just thought to save few mouse clicks there. If you want multiple mapping sets - just copy current mappings.json and rename it for future loading. Or I could add "Mappings saved" msg in the modal upon successful save, so it gives an indication that pressing that Save button actually caused something to occur?

On Load mappings, It calls for a file picker, reads any json file you selected, and overwrites mappings.json with whatever file you loaded. The loaded mappings become the new saved state.

Edited 22 hours ago by GrimReaper

[GrimReaper 4913]

v1.1

- Mapping Save/Load status messages added

- Delete all rows button added

- Mapping input field is a combo-box now (you can both type-in or use dropdown; you'll get suggestions as all unique tags collected based on current album selection)

emby_album_tag_importer.py

Edited 20 hours ago by GrimReaper

[GrimReaper 4913]

Was playing a bit with colors to better indicate workflow/selection, tell me which version works better.

v1.1b

emby_album_tag_importer.py

 

 

Edited 17 hours ago by GrimReaper

[GrimReaper 4913]

v1.1b2
- GUI reworked (Mapping modals behavior adjusted)

emby_album_tag_importer.py

[user24 365]

This is small quick follow-up test on V1.0  (will catch up soon)

Found the JSON file. I suppose I was initially expecting a pop-up window like "Save As" rather than "Save". 

It seems to Save ok (e.g.)

(Hmmm - this has actually given me a vague idea for a completely different project I'm working on, where I need to map Album Artists to their IDs).

11 hours ago, GrimReaper said:

On Load mappings, It calls for a file picker, reads any json file you selected, and overwrites mappings.json with whatever file you loaded. The loaded mappings become the new saved state.

Yep. Found this out the hard way. I need to read the instructions!!!

Just me getting used to how it works.

Moving on to the newer versions now...

[user24 365]

9 hours ago, GrimReaper said:

Was playing a bit with colors to better indicate workflow/selection, tell me which version works better.

Well, this was a big change!!!

If I was only ever updating a few Albums, or even all (e.g.) "The Beatles" albums in bulk, then the standard white background would be fine, because any silly mistakes could quickly be corrected. BUT real-life use-case (as per images above) is more likely to be updating at top folder-level (e.g) "Bb (a-m)". Therefore green/red is the way to go. It's a good idea! But see below re: color...

Two possible improvement changes:

1. CUSTOM tag in orange is too close to red in the color spectrum, now clashes with green, and seems like a "warning" signal. Now that green is the background, all three tag selections would possibly be better if they were 'above' green - ROYGBIV - from left to right? Please can you pick the best tones that you think will work.  Second thought - perhaps Blue for all three or even just the Gray/White palette(???), as the position and name delineates which tag has been selected, and they are all are tags, as such. Maybe simple is better - or we end up with a rainbow!!!

2. Just a thought - but I'm not too fussed either way - RELEASETYPE, ROONALBUMTAG. CUSTOM possibly dont't need the "Tag" after them inside the buttons. There is plenty of room, but it may look better without? You be the judge.

Thanks!

[GrimReaper 4913]

50 minutes ago, user24 said:

Therefore green/red is the way to go. It's a good idea!

Just wanted you to say that; after 30 mins testing on colored version, opening plain one was literal WFT moment - you'll se after some usage. Anyway, that'll be the branch for further development.

50 minutes ago, user24 said:

1. CUSTOM tag in orange is too close to red in the color spectrum, now clashes with green, and seems like a "warning" signal. Now that green is the background, all three tag selections would possibly be better if they were 'above' green - ROYGBIV - from left to right? Please can you pick the best tones that you think will work.  Second thought - perhaps Blue for all three or even just the Gray/White palette(???), as the position and name delineates which tag has been selected, and they are all are tags, as such. Maybe simple is better - or we end up with a rainbow!!!

You are right, there's actually no reason for METHOD buttons to be accented at all, let alone in three colors - likely a legacy mental map from some of the previous iterations - not even a single blue (tested), plain white/black is in line with general theme and works just fine.

50 minutes ago, user24 said:

2. Just a thought - but I'm not too fussed either way - RELEASETYPE, ROONALBUMTAG. CUSTOM possibly dont't need the "Tag" after them inside the buttons. There is plenty of room, but it may look better without? You be the judge.

I'm fine either way, maybe I'm slightly more inclined towards having word Tag there, but I won't be using it anyway so I'm not bothered.

v1.2
- GUI refined (color accents dropped, button tags)

emby_album_tag_importer.py

Edited 8 hours ago by GrimReaper

[user24 365]

16 hours ago, GrimReaper said:

- Mapping input field is a combo-box now (you can both type-in or use dropdown; you'll get suggestions as all unique tags collected based on current album selection)

Still catching up...

Yes, so if I choose All Albums for an Artist, then I get all the options:

The mapping 'tick' notification upon "Save" is useful.

Here's something like a more real version that I'd be keeping for use and updating as necessary:

Tried the export log file - no problems.

Many of these enhancements seem very professional-grade now.

Let me know if there is any other specific function update you want me to try that I may have missed?

Otherwise, I'm going to start working through my "Top 100" Album Artists and see how things progress. Cheers!

[user24 365]

@GrimReaper Please could you help check/confirm the following sequence, when you get a spare moment - no immediate hurry...

• Process Mode - ADD Tags
• Import Mode - REPLACE Tags
• Tag Method - RELEASETYPE
• Tag Method - Map specific RELEASETYPE...

The RELEASETYPE is mapped successfully and overwrites what was there. But I think (I have tried a few times) this also deletes any existing ROONALBUMTAG tags as well.

My General assumption - as you work down the steps is that the REPLACE function should only apply to the underlying tag group that is selected either RELEASETYPE or ROONALBUMTAG or CUSTOM, but not all three together.

I also tried the reverse - REPLACE ROONALBUMTAG and then RELEASETYPE gets deleted. I may be doing something wrong, or this may be how it is currently configured to work. The GUI implies to me that only the one that is selected should be replaced. Am I interpreting correctly???

If possible, my preference would be to just replace the selected tag grouping. There is always CLEAR to reset everything. Thanks.

Edited 2 hours ago by user24

[GrimReaper 4913]

2 hours ago, user24 said:

@GrimReaper Please could you help check/confirm the following sequence, when you get a spare moment - no immediate hurry...

• Process Mode - ADD Tags
• Import Mode - REPLACE Tags
• Tag Method - RELEASETYPE
• Tag Method - Map specific RELEASETYPE...

The RELEASETYPE is mapped successfully and overwrites what was there. But I think (I have tried a few times) this also deletes any existing ROONALBUMTAG tags as well.

My General assumption - as you work down the steps is that the REPLACE function should only apply to the underlying tag group that is selected either RELEASETYPE or ROONALBUMTAG or CUSTOM, but not all three together.

I also tried the reverse - REPLACE ROONALBUMTAG and then RELEASETYPE gets deleted. I may be doing something wrong, or this may be how it is currently configured to work. The GUI implies to me that only the one that is selected should be replaced. Am I interpreting correctly???

If possible, my preference would be to just replace the selected tag grouping. There is always CLEAR to reset everything. Thanks.

Hmmmm, not sure I interpreted all of that correctly, as if I did I'm afraid that would not be feasible, so I think it would be best if one real-case scenario was provided to assure we're on the same page here (as there's so much underlying logic implemented in the script now that one wrong assumption might have multiple consequences):

- Track has this and this RT tags

- Track has this and this ROON tags

- item (in Emby) had this and this tags (or was blank) 

- This Import mode was selecletd

- This Tag method was selected

- These are the results I got (Item in Emby had these tags now after process run) 

- This is what I expected (Item in Emby to have these tags after process run) 

We can discuss afterwards, once clear picture is obtained. 

Thanks

Edited 1 hour ago by GrimReaper

[user24 365]

16 minutes ago, GrimReaper said:

We can discuss afterwards, once clear picture is obtained. 

OK, leave it with me for a while. Best if I just keep working through using it for real now, as opposed to repeatedly testing out the separate functions on a limited basis?

A good stable logical workflow might emerge that works well every time, and I'll know what to expect OR I might hit some more random unknowns?

[GrimReaper 4913]

3 minutes ago, user24 said:

OK, leave it with me for a while. Best if I just keep working through using it for real now, as opposed to repeatedly testing out the separate functions on a limited basis?

A good stable logical workflow might emerge that works well every time, and I'll know what to expect OR I might hit some more random unknowns?

OK, but to clarify current usage limitations:

the only difference between ADD and REPLACE modes is what is done with the existing tags in Emby: they're either retained or deleted on Process run, as per mode selection, regardless of the method selected below. 

I.e. Emby doesn't know the source of the tags it has, it only replies with "These are the tags currently available on the album, what should I do with them?" when queried. ADD mode retains them, REPLACE mode wipes them all before importing/adding manually the new tags according METHOD selection.

[user24 365]

26 minutes ago, GrimReaper said:

Emby doesn't know the source of the tags it has

You have explained it well enough. Thanks! That clarifies things nicely. It's somewhat like the diagram I sent you.

1. Mp3tag - separate fields
2. Importer - separate selection
3. Emby Default pages  - combined (it's the same "Tag" field in Emby - duh!)
4. Emby Custom page - split page view

So even though that's the process flow, in real-use I do: 1, 2, 4 and don't even bother looking at 3, it becomes somewhat invisible and irrelevant (but it's not).

So my brain then thinks the tags remain separate all the way through. Funny (but stupid) how you can mislead yourself.