Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: External Tags (Read 50956 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: External Tags

Reply #350
manmower:  the external tag for streams is only created automatically if you actually attempt to add tags to the stream;  just opening "Properties" from the context menu, and closing it, does not automatically create an external tag for a stream.  If the stream already has an M-Tag, I don't know what happens.

Re: External Tags

Reply #351
Hi Case (or anyone else who can answer), quick question, is there a way to distinguish whether attached cover art is stored internally or externally? I often remove a cover, it doesn't work, then the penny drops that I need to first Commit external tags, and try again. I also prefer to store cover art in external tags; it would be nice to track down all of the files in my library that still have covers attached internally. I was thinking a %__covertype% field or similar could come in handy in both cases, if I'm not missing something. Thanks!

Re: External Tags

Reply #352
That isn't supported at least at the moment. If there's a simple way for me to implement that I can add it.

Re: External Tags

Reply #353
You probably have thought of this and found it not to be "a simple way", but if not, here's from some ignorant swiney snout who totally sucks at coding:

* Could be stored in a ZIP or 7z file with a different suffix (like fb2k-component does) and name each picture something like
0 Front = description.jpeg for common "front"
1 Back = description.jpeg for file 1's back that is not common to all
1 Front = otherdescription.=0 if file 1 uses the 0 Front file but a different description
etc.
* Using 7-zip (which is FOSS) you can probably duplicate files without size penalty, and accommodate "file names" as long as hell.
* One tagset per file rather than per folder? Easier.

Re: External Tags

Reply #354
I think the point is how to implement an exposed check to tags which should output true when it's an external tag and false when it's on file. And it should be query compatible (since that's the main aim)
Code: [Select]
$isExternalTag(artist)
BUT some entities are not a tag per se, like the cover, which has no TF variable. That would require another TF function for those specific cases (not sure if there are more than the cover).
Code: [Select]
$isExternalTagCover()

Then it further complicates its use with m-tags, since such function would only check if the tag is provided by the plugin, but it would not be 100% sure they are from the files (may be from m-tags). I suppose people use one or another plugin but its worth warning about it if such feature is aded.

Re: External Tags

Reply #355
A couple of observations using .tag files, none are a big deal.

* For files that have no tags at all, I can create external tags and remove external tags, but commit to file does nothing.
That is maybe OK to leave in as a warning?
* Every now and then, commit will "fail": having library search for %__tagtype% HAS xt while it is running, there will be some odd folder with a file left in the search. Yes sometimes the library is lagging and it "disappears" after a "Reload info from file(s)", but most often not.
I don't know if it actually gets as far as to writing tags to the audio files (i.e. only the removal stage fails).
No big deal: I just have to run it once again.

Tested right now on v2 64-bit, but I noted the second item for a long time.

Re: External Tags

Reply #356
Oh, and:
I discovered that failure to commit sometimes happens on part of a multi-track ("image") file.
Then the .tag file is gone nevertheless, so any tag updates are lost.

Re: External Tags

Reply #357
Hm. foo_external_tags and foo_renamer aren't always the best of friends, at least not on the EXFAT file system:
Old name:
AbBa_Eagle.mp3
AbBa_Eagle.mp3.tag
should be renamed to nearly the same, but the first "b" capitalized. Unfortunately, Windows (11) and EXFAT don't think I need to correct case, so a file could easily be reverted back.
But foo_external_tags is case sensitive, and then it doesn't recognize the .tag file.

Too bad to have to correct Microsoft's fuckups, but I guess that is part of the game when working on Windows.
(Feel free to shout back "yes, do that - avoid EXFAT!")

Re: External Tags

Reply #358
Need help which right now hopefully can save a couple of days' labour, if the following works - but I'm asking before firing up fb2k again.

* Hard drive crash [well maybe, I have not yet taken the chance of firing it up again] at the end of a major tag clean-up. Might have found some bad sector, or might have shut down as a safety precaution over running too hot.

foo_external_tags is installed.

Can I get these tags transferred to a backup drive (well the now-in-the-works copy of the backup drive) as follows
* Without connecting any drive, ask foo_external_tags to create (SQL) tags for everything, and then
* Connect a backup drive which has - with a couple of renamed exceptions that I will find - the same files (after making sure it identifies at the same drive letter), and
* Then have these updated tags from current database in foo_external_tags' SQL database, ready to commit
?

I probably need to disable fb2k's library rescanning at startup, and I probably need to do that before I fire it up?

Re: External Tags

Reply #359
I'm sorry I can't provide a perfect answer at the moment, but what you are attempting sounds doable. I'm still on the road and can't conveniently access my development machine. Remember that you can always backup your foobar2000 profile and all the cached info there remains intact. If the attempt doesn't work I can make adjustments to the component to make it possible.

 

Re: External Tags

Reply #360
I discovered that failure to commit sometimes happens on part of a multi-track ("image") file.
Then the .tag file is gone nevertheless, so any tag updates are lost.
That at least is definitely a bug. I'll take a look.

Hm. foo_external_tags and foo_renamer aren't always the best of friends, at least not on the EXFAT file system:
Old name:
AbBa_Eagle.mp3
AbBa_Eagle.mp3.tag
should be renamed to nearly the same, but the first "b" capitalized. Unfortunately, Windows (11) and EXFAT don't think I need to correct case, so a file could easily be reverted back.
But foo_external_tags is case sensitive, and then it doesn't recognize the .tag file.
If foo_renamer fails at file renaming I'll have to fix that. Thanks for letting me know.