Support access to ID3 URL link frames

[mforkel]

ID3 defines a set of URL link frames. If LMS provided acces to them, user interfaces could include support for following those links. See lms-material issue #629.

[mw9]

Are URL link frames supported in any commonly used audio file format other than mp3 ? Or would this just be an ‘mp3 only’ feature ?

Do you have a use case or concrete example that might entice someone into spending the time to implement something ?

[mforkel]

Well, I'm not an expert on ID3, but according to Wikipedia, ID3 tags were designed with MP3 in mind but "are an independent part of the MP3 file and should be usable elsewhere. In practice, the only other formats that widely use ID3v2 tags are AIFF and WAV".

I would like to embed in my music files links to sources that provide additional information like Discogs or an artist's website. If user interfaces like the LMS plugin Material were then to support these embedded links, I could access information like credits or background stories easily while listening to the music.

[mw9]

Well, I am no expert either.

The majority of my library is in mp4/m4a form. (Apple Lossless, mostly). I am not aware of any equivalent url tag available in that format.

Some of my library is in flac form. I believe that it is quite liberal in naming tags, but I don’t know if there is a url tag in common use.

From my point of view, a url tag that could only be used within the id3 scheme would be of little value. There would have to be some kind of common, supported, “standard” to get them into other file formats before I could be interested.

It sounds like nice idea, but I do wonder if there is sufficient support in the “tagging universe” to make it viable.

And, of course, url links tend go stale in time.

[mforkel]

I would be surprised if a majority of the existing audio formats suddenly decided to adopt a common tagging scheme. So we only have MP3, MP4, WMA, and WMV supporting embedded ID3 (again, according to Wikipedia). If LMS was extended to provide tags for all audio formats, it would have to apply some proprietary mechanism, e.g. companion ID3 file for non ID3-aware formats. But then, how would one create such files?

Until now, I assumed that the track-related information I see in the Material UI comes from ID3 tags. But I only have MP3 files. So how do other formats like FLAC store information that MP3 files store in ID3 tags? And how is that information exposed by LMS? Mp3tag, the MP3 editor I use, supposedly supports quite a number of audio format, FLAC being one of them. But then ID3 does not seem to be the standard tagging scheme for FLAC.

[terual]

FLAC uses Vorbis comments for metadata. If you are interested in the subject you can look at the source code of the parsing library used by LMS: https://github.com/andygrundman/Audio-Scan/tree/master/src. Here you can see how the different audio formats and metadata formats are parsed during scanning.

In LMS subsequently a mapping from the idiosyncratic metadata fields to LMS fields takes place so in the end it doesn't matter which metadata format is used.

[mw9]

@mforkel

Do these url tags show up when you browse into 'More info|View tags' ?

[mherger]

For the time being you could probably just add those URLs to the comments and browse from there?

[mforkel]

Do these url tags show up when you browse into 'More info|View tags' ?

No, neither in LMS's own UI nor in Material. Tested with a WXXX tag.

[mforkel]

For the time being you could probably just add those URLs to the comments and browse from there?

True, but the UI most likely would not recognize them as URLs and so I had to do something like select + copy + paste + follow to open the link.

[mw9]

Do these url tags show up when you browse into 'More info|View tags' ?

No, neither in LMS's own UI nor in Material. Tested with a WXXX tag.

@mforkel

My findings are different. I can see both WXXX and WPUB tags both in the LMS Default UI, and in Material. The WXXX tag (user defined URL) is "renamed" to the description that is specified in the tag, rather than WXXX.

I did note that the 'More info|View tags' menu is not always available - I think when browsing through "Disks & Folders".

[mw9]

For the time being you could probably just add those URLs to the comments and browse from there?

True, but the UI most likely would not recognize them as URLs and so I had to do something like select + copy + paste + follow to open the link.

Well, I find that that does work in Material. But not in either of the Default or Classic skin.

Some 15 years ago, a change was made to turn http links in comments into an html "clickable" link. Refer https://github.com/Logitech/slimserver/commit/529f77be51f248b9db31ade9e69c55f8d1e74f99

This turns an http link into a HTML <a> tag. It would need updating to accomodate https.

The change is taken up in the trackinfo menu, Slim::Menu::TrackInfo. https://github.com/Logitech/slimserver/blob/public/8.4/Slim/Menu/TrackInfo.pm#L788

The same process is also undertaken in Slim::Web::Pages::Common::AddSongInfo. https://github.com/Logitech/slimserver/blob/public/8.4/Slim/Web/Pages/Common.pm#L168

The change refers to Bug: 8604, which is no longer available online. The bug report might throw light on the intention.

To make the URL clickable would require something to be done in the LMS skins to make them recognize the HTMLish nature of the comment field. I don't know quite what. I don't know how/why Material succeeds in doing it.

It makes no sense, and is rather messy, in the Squeezeplay/Jive UI. Perhaps it should really be done outside of the trackinfo menu, and left to the rendering process/skin to do.

While looking further at comments, I think the "collapse" of multiple comments, where they exist, into a single line separated by a "\" might be looked at. Perhaps treat them as multiline comments with a newline separator instead. Edit: Submitted PR #846 in follow up.

[michaelherger]

Thanks for your investigation, @mw9! Unfortunately I'm not sure the TrackInfo part is handled well in the Default skin: it would simply print the <a href=...> tag in the menu.

(that's after the https change you mentioned)

We have to escape HTML in such content for security reasons. Otherwise a prepared file could lead to XSS.

Material is doing this client side, in the browser, using JS. Maybe we can steal from it 😁.

[michaelherger]

I added a few tweaks to 8.4. It should now render the link in comments correctly, at least in the Default skin. I didn't take care of Classic/Light.

[mforkel]

My findings are different. I can see both WXXX and WPUB tags both in the LMS Default UI, and in Material. The WXXX tag (user defined URL) is "renamed" to the description that is specified in the tag, rather than WXXX.

Thanks for checking that! You're right, I can see WPUB tags, too. But not WXXX tags. The reason might be that the MP3 tag editor I use (Mp3tag 3.18) doesn't allow me to enter a description, just a URL value. I will contact the author of Mp3tag about this.

[mw9]

I added a few tweaks to 8.4. It should now render the link in comments correctly, at least in the Default skin. I didn't take care of Classic/Light.

I would never have known how to do that. It seems to be working nicely !

I even checked a "query" url, with a ?, and & terms. It worked ! So the regex seems to be good for both plain text and text passed by the template through the html filter.

I don't know how to get at the "Light" skin, but the equivalent change to the xmlbrowser template in the EN section of the templates does seem to work in "Classic". Can make a PR if you wish.

I made the equivalent change here: https://github.com/Logitech/slimserver/blob/public/8.4/HTML/EN/xmlbrowser.html#L258

I've never really understood how web page rendering hangs together. Sometimes createLinksInComment is called directly from Slim::Web::Pages::Common::addSongInfo, and sometimes through the invocation of the parseURIs filter by the template. I might understand it one day. 😄

Material, unsurprisingly, no longer works as it did.

I still think the presentation of comments can be improved, particularly collapsing multiple comments, and multi-line comments. But that's for another day.

I think this is a worthwhile exercise. Even if links do go stale...

[michaelherger]

I don't know how to get at the "Light" skin, but the equivalent change to the xmlbrowser template in the EN section of the templates does seem to work in "Classic". Can make a PR if you wish.

Thanks for the hint. I applied that change.

I've never really understood how web page rendering hangs together. Sometimes createLinksInComment is called directly from Slim::Web::Pages::Common::addSongInfo, and sometimes through the invocation of the parseURIs filter by the template. I might understand it one day. 😄

TBH: I considered removing the code from addSongInfo, as it IMHO wouldn't work. But it's not used in current skins. I should probably still remove it...

Material, unsurprisingly, no longer works as it did.

I actually can't get it to work at all. Neither with 8.3 nor 8.4. And tbh. I wouldn't know why the current change would break this in Material: it's mostly about rendering in the Default skin. Material doesn't use this, but the raw data. And that data response has not changed.

That said: I only tested with a https link which didn't render the link before at all. Did you test with http or https?

[mw9]

TBH: I considered removing the code from addSongInfo, as it IMHO wouldn't work. But it's not used in current skins. I should probably still remove it...

I'll try that locally and see what happens.

And tbh. I wouldn't know why the current change would break this in Material: it's mostly about rendering in the Default skin. Material doesn't use this, but the raw data. And that data response has not changed.

The raw data has changed. It no longer has the <a>...</a> tag in the text of the comment.

That said: I only tested with a https link which didn't render the link before at all. Did you test with http or https?

Both. My guess is that Material might be looking out for that tag, and just "not escaping" the HTML when it finds it. I guess that, now, it would need to look out for the parseURLs attribute that is provided, and invoke the parseURIs filter.

I haven't looked inside Material to figure out how it was "getting it right". You have, kindly, removed the need...

[michaelherger]

@CDrummond - did you do anything particular to make links in comments etc. work? Or are you simply not escaping HTML from incoming data?

[mw9]

Well, I don't have too much knowledge here, but:

As far as I can see, Material uses the JSON-RPC api to collect jive menus from LMS, in much the same way as SqueezePlay would. (i.e. using by 'menu' parameter in the query) [1]. Slim::Control::XMLBrowser is the LMS responder. So it is not using template toolkit like the Default and Classic skins do.

I believe that the comment text is simply interpreted as being in html format. In fact, any jive window item with a textarea attribute would be interpreted this way. [2] Edit: The wrap attribute in the comment item triggers this behaviour, I think.

I base that hypothesis on this piece of the source code: https://github.com/CDrummond/lms-material/blob/master/MaterialSkin/HTML/material/html/js/browse-resp.js#L599

And the simple experiment of putting valid html into a comment and observing the result. Edit: Also works with a lyrics tag.

The parseURLs attribute would not made visible by Slim::Control::XMLBrowser.

[1] It's a long time since I delved into the generation of the jive menu structure by Slim::Control::XMLBrowser. Presence of a menu parameter ine the query switches between a regular CLI browse response and the response needed by jive.

[2] Slim::Control::XMLBrowser creates these types of objects when the query includes a menu parameter. I don't recall the gory details.

[mforkel]

You're right, I can see WPUB tags, too. But not WXXX tags. The reason might be that the MP3 tag editor I use (Mp3tag 3.18) doesn't allow me to enter a description, just a URL value. I will contact the author of Mp3tag about this.

Just to confirm: Now that I know how to properly enter WXXX tags with Mp3tag, I can see them in the LMS 8.3.0 user interface and in Material 3.0.2. Could I convince you guys to make them easier to reach (an clickable :-)?

[CDrummond]

@michaelherger No, AFAIR, Material is just showing the info its provided - no specific code to handle this.

[michaelherger]

Just to confirm: Now that I know how to properly enter WXXX tags with Mp3tag, I can see them in the LMS 8.3.0 user interface and in Material 3.0.2. Could I convince you guys to make them easier to reach (an clickable :-)?

Not easily: the scanner module (https://github.com/andygrundman/Audio-Scan) would return custom tags like TXXX and WXXX with the description as the identifier. As this description could be anything, it's hard to know what that was.

What potentially could be done is to promote the "View Tags" items to the main track info menu. Or at least those values which aren't imported (artist, title, etc.) anyway. It would add to the long list of menu items, potentially adding many useless items...

I could imagine this feature to be implemented in a plugin. The functionality is likely interesting for some, but might be too much clutter for many. Hmm... as if I needed yet another plugin idea! 😖

[mforkel]

Not easily: the scanner module (https://github.com/andygrundman/Audio-Scan) would return custom tags like TXXX and WXXX with the description as the identifier. As this description could be anything, it's hard to know what that was.

What potentially could be done is to promote the "View Tags" items to the main track info menu. Or at least those values which aren't imported (artist, title, etc.) anyway. It would add to the long list of menu items, potentially adding many useless items...

With hesitation, because I wouldn't be the one who would do the work, but ...: How about a new menu "Links" that only contains those tags whose values seem to be a valid URL, selected by a regular expression. and don't have well known tag names? For regular URL link frames, the menu item label could be a - potentially local specific - predefined name, for other tags it would hopefully be the description of a WXXX tag.

[michaelherger]

I was toying with the idea of having an option to define additional tags to be displayed in a higher level. Eg. tell LMS to show whatever you named the WXXX tag, and parse its URL. And optionally provide a more human readable title field. In the Default skin this would be shown on the track info page. On device it would be in the "More info" or similar section.

That's more work for the user to configure. But OTOH if we wanted to parse all tags at the higher level, we'd always have to re-scan the audio file when that menu is shown. Right now this only happens if you drill down to the View Tags menu.

[mw9]

I was toying with the idea of ...

One way might be to automatically append W??? tag(s) to the existing comments field, if the user so chooses. As you say, would need translation of W???, and "special handling" of the user defined WXXX tag. (Same might apply to TXXX tag).

Possibly Audio::Scan might be persuaded to mark WXXX and TXXX as such, without breaking existing interface. Somehow.

Edit: Probably easy. Perhaps have it return additional WXXX & TXXX arrays, containing the same data.

[michaelherger]

Relying on Audio::Scan is painful, as it means all binaries would have to be re-built to support this feature... Any thoughts about the above suggestion? I have working code for a POC, but haven't figured out the best way to configure it yet.

[mw9]

I agree that Audio::Scan reliance would be painful, and not so easy-peasy because it would need to be done in the perl/XS/c framework.

But OTOH if we wanted to parse all tags at the higher level, we'd always have to re-scan the audio file when that menu is shown. Right now this only happens if you drill down to the View Tags menu.

I think that having to re-scan the audio file for that menu might be a problem for some. Many users access files over a network, and I know from my own experience that the View Tags menu can sometimes be irritatingly slow to load when the file is somewhere on my own network. I do quite regularly access "More info" on my devices.

haven't figured out the best way to configure it yet

For configuring, would it be viable to present the user with a list of "known" URL tags to pick from, and also allow the user to specify his own URL tags and preferred description to include in the list ? For MP3/ID3 that would be essential to handle the WXXX tags.

I'm not clear on what might be needed for other tagging schemes. I think Vorbis is free form ? In which case any tag that the user specifies. Hopefully he won't conflict it with an already "recognised" tag. MP4 does, I think, allow for user defined tags in some form, but it's been a while since I looked. I can't remember, or perhaps have never known, how Audio::Scan reports them.

I have no practical experience with the various tagging programs out there, and how they do things. I guess many (power?) users would be using one. Might that generate user support issues ?

[mw9]

@CDrummond

@michaelherger No, AFAIR, Material is just showing the info its provided - no specific code to handle this.

Is it treating the text from an info item with a window.textarea attribute as if the text really was in html ? That would explain what we observed. Comments and Lyrics would show up as such items, I think.

[michaelherger]

I think that having to re-scan the audio file for that menu might be a problem for some. Many users access files over a network, and I know from my own experience that the View Tags menu can sometimes be irritatingly slow to load when the file is somewhere on my own network. I do quite regularly access "More info" on my devices.

Just when I thought "oh well... it's a single track, won't be too bad!". What setup would that be? In my testing I can't really see a notable delay (LMS on Pi3, files on an entry level ARM based NAS from 2018).

For configuring, would it be viable to present the user with a list of "known" URL tags to pick from, and also allow the user to specify his own URL tags and preferred description to include in the list ? For MP3/ID3 that would be essential to handle the WXXX tags.

Yep, was playing with something like that, based on https://picard-docs.musicbrainz.org/downloads/MusicBrainz_Picard_Tag_Map.html.

I have no practical experience with the various tagging programs out there, and how they do things. I guess many (power?) users would be using one. Might that generate user support issues ?

(Self declared) Power users always generate support issues 😁.

[mw9]

Just when I thought "oh well... it's a single track, won't be too bad!". What setup would that be? In my testing I can't really see a notable delay (LMS on Pi3, files on an entry level ARM based NAS from 2018).

Well, I've just tried, and I can't see a particularly noticeable delay either, now. Similar set up, Sheeva as a NAS, LMS on PCP Pi3. Both directly connected via ethernet to router.

So, I don't know what was causing the issue that I had noted. I was using Material at the time, but I still am. Perhaps something else entirely, that has just "gone away".

I've never tried connecting one or both of these devices via wireless, I don't know what that would do. I could imagine circumstances in which wireless traffic might become congested, but I don't know if a problem in practice. A 55MB file would take about 8 seconds to download in full on a link achieving 50Mbps, so I suppose that might have potential to congest matters. I guess most of the time Audio::Scan wouldn't be doing that, but I've never made a study.

Yep, was playing with something like that, based on https://picard-docs.musicbrainz.org/downloads/MusicBrainz_Picard_Tag_Map.html.

That is an excellent presentation. If I get time in January I might see if I can draft up something similar for LMS. It's probably already in the Wiki...

[mw9]

So, I don't know what was causing the issue that I had noted. I was using Material at the time, but I still am. Perhaps something else entirely, that has just "gone away".

"Irritatingly slow to load menu" has started happening again. But it's not restricted to the "View Tags" sub-menu of "More info", it also impacts the main "More info" menu. Perhaps it is related to browse session caching, I'm not sure. That's for another day.

Also: Some MP4/M4A audio files have their tags right at the end of the file, after the audio. I don't know if Audio::Scan just jumps right there, or whether the whole file has to be read. I would hope the former.

[michaelherger]

https://wiki.slimdevices.com/index.php/SlimServerSupportedTags.html lists some tags - but it's certainly outdated.

That scan doesn't do any magic beyond what the music scanner does. Would that be that slow, too?

[mw9]

That scan doesn't do any magic beyond what the music scanner does. Would that be that slow, too?

That is my surprise, the More Info menu is slow when using the networked drive as music source. But it shouldn’t be accessing the file/drive until I enter the View Tags menu. But both menus are similarly slow.

I’ve just compared with the same drive (it’s a usb stick) plugged directly into a USB socket on the pi/LMS server. Both menus become reasonably crisp, including View Tags.

All this using Material skin as the interface. I have yet to investigate the standard web interface, or Jive menus for that matter.

I’ve only recently started trialling pCP, and I’ve only recently been using a networked music drive as source. So I cannot rule anything out or in. I think I need to make a more systematic investigation before I can draw any useful conclusion. That won’t happen until January.

[mherger]

I think the sub menus are created at the same time as the main track information menu. It's just not expanded by default. This is more of a UX decision than technical.

Could it be the remote drive goes to sleep and needs a moment to wake up? For the scanner this would be more or less irrelevant, as it would only have to wake it up once for the scan. But in that menu it could be annoying, if all the rest of the information was pulled from the database.

[mw9]

Could it be the remote drive goes to sleep and needs a moment to wake up?

That may well be the cause, and I shall follow up further. Right now, it’s back to working fine, as in “Both menus become reasonably crisp, including View Tags.” That’s using the network drive. And I do not know why it is now working fine.

My ASSumption about the “More info” menu only using the DB seems to be almost right (subject to what a plug-in or UI might do in addition to ‘pure’ LMS).

What I had overlooked, or just didn’t know, was this: when “More info” initially retrieves the track object, a validity check will be carried out against the source audio file by Slim::Schema::find. So there will always be some disk activity when “More info” is executed. And, if the drive is asleep at the time, there may be delay…

Perhaps less likely: a problematic stat call, or something else, during that find might cause LMS to think that the file has changed, at which point it would be rescanned on the fly. That could also cause delay.

Anyway, it seems plausible that my initial concern about “having to re-scan the audio file for that menu” may have been informed by something dodgy or quirky within my own network set up. Because when it works nicely, as it is now, “View tags” is “reasonably crisp”.

[michaelherger]

I've added an "Advanced Tag View" plugin to 8.4, which allows you to define the tags you want to see on an upper level, without drilling down to the "View Tags" menu. Please give it a try!

[mforkel]

Please give it a try!

Wow, thanks! Is there an easy way for me to upgrade to 8.4? Will you be releasing it in the foreseable future?

[michaelherger]

You can get it from https://downloads.slimdevices.com/nightly/?ver=8.4. There's no release plan, though. It currently doesn't have many changes compared to 8.3.1. This Advanced Tag View really is the only larger change so far. You should be able to install that build right over what you currently have.

[mw9]

Nice.

I think you might remove the predefined WXXX from the settings. Audio::Scan will never return a tag by this name, as it uses this tag's 'Description' field to actually name the tag. So I think its presence in the Standard URL tags section is confusing. It is, essentially, a 'no-op'.

Also nice is that this new feature is by no means confined to URL tags, or mp3/ID3.

Possibly an added hint in the "Additional tags to show" preference setting, to refer to the "View Tags" menu? Perhaps something like:

"Tag name" refers to the actual tag, as stored in the file, eg. "WEBSITE". The "View Tags" menu shows these. The "Name to be displayed" is a more user friendly name to be used in the UI. "URL" defines whether the field contains a URL. In this case UIs able to link to URLs can render the content with a link.

As a follow up, it might be worth investigating if the parseURLs attribute in the menu item can be made visible, safely, by Slim::Control::XMLBrowser. Key point as that it must not break SqueezePlay. I can look at SqueezePlay in the new year if you think that might be worthwhile. Material seems to be using this route to generate its display, and I suppose there are other UIs too (iPeng?), but I haven't used them. I'd would guess that all should be well, provided they ignore unknown attributes.

[mforkel]

Yes, very nice and generic.

I agree with @mw9 that in the list Standard URL tags, the last entry User defined URL, which I guess stands for WXXX tags, might not be needed.

I have to admit that I havn't figured out how the plugin extends the user interface, though. I configured one Additional tag with name DISCOGS, display name Discogs and activated URL. But when I look at the information for a track that has such a tag, I don't see it. But I can see the tag's description and URL value under View Tags.

[mw9]

@mforkel

LMS caches menus for a period of time after generating them. So you may have been seeing a cached version of the menu, generated before you updated the preferences. I forget for how long.

Try again later. Or, if impatient, stop LMS, delete the cache.db file, and start LMS again.

[mforkel]

Try again later. Or, if impatient, stop LMS, delete the cache.db file, and start LMS again.

Yep, the cache was the culprit. After deleting it, I can now see and follow the link. Very nice!

The WXX tag had been there for a couple of days. Other users might fall into the same trap. As I was, they are probably unaware of the menu cache and expect to see their links once they have changed the configuration of the Advanced tag view plugin. So if possible, could the plugin clear the cached menus after a change to its configuration? Otherwise, an additional hint would be helpful.

[michaelherger]

Thanks for your feedback and suggestions, @mw9 & @mforkel! I'll remove WXXX, add your hints about the "View Tags" menu.

It actually wasn't a caching issue, but a failure to re-initialize the menu handler correctly. Should be fixed soon.

@CDrummond - I was considering adding the renderURLs hint to menu items which would contain links. Eg.

            {
                "parseURLs": 1,
                "text": "Official artist webpage: http://www.artist2.com",
                "action": "none",
                "type": "text",
                "style": "itemNoAction"
            },

parseURLs would tell you that the content can have a link. Something like the following change would render the link in Material:

diff --git a/MaterialSkin/HTML/material/html/js/browse-resp.js b/MaterialSkin/HTML/material/html/js/browse-resp.js
index fcc933aa..bf1bb4a8 100644
--- a/MaterialSkin/HTML/material/html/js/browse-resp.js
+++ b/MaterialSkin/HTML/material/html/js/browse-resp.js
@@ -345,6 +345,10 @@ function parseBrowseResp(data, parent, options, cacheKey, parentCommand, parentG
                     i.type = "text";
                 }

+                if (i.parseURLs) {
+                    i.title = i.title.replace(/\b(https?:\/\/[A-Za-z0-9\-_\.\!~*'();\/?:@&=+$,]+)/, "<a href=\"$1\" target=\"_blank\">$1</a>");
+                }
+
                 if (isAppsTop && i.actions && i.actions.go && i.actions.go.params && i.actions.go.params.menu) {
                     if ("myapps" == i.actions.go.params.menu) { // mysqueezebox.com apps
                         if (i.actions.go.params.item_id) {

[CDrummond]

@michaelherger Change looks fine to me - I'll add to Material, for 3.1.0

[mforkel]

It actually wasn't a caching issue, but a failure to re-initialize the menu handler correctly. Should be fixed soon.

@mherger Good idea to add the "official" ID3 tag names to the description text in the UI. Everybody seems to use their own names.

I'll happily test with a new nightly build - and a different track :-)

[mforkel]

I have now tested 8.4.0~1671712769. New tags showed up immediately (tested with WXXX). But I haven't figured out the difference between Show tags in "More Info" and Show tags at the top level. It seems to me I can see the tag once I select More for a track with both settings. What's the top level?

[michaelherger]

You probably wouldn't see a difference in the Default web skin, as it's expanding the "More Info" menu at the top level already. But on the player UI or in the Material skin you'd see the difference.