Metadata not showing in most players? about gmusicproxy HOT 8 CLOSED

OK, I'm taking a closer look at VLC, and it's not actually showing anything more than the #EXTINF tags in the .m3u file itself... In fact, if I wget an individual song (http://localhost:9999/get_song?id=Tl446vcudszpei5peqwwbjcbnya for example), and run mp3info on it, it reports " does not have an ID3 1.x tag"

I'm now wondering if I have a botched install... Maybe eyed3 isn't working? Or maybe I'm expecting something that isn't possible? I will start digging into weather or not all the dependencies were met and report back...

from gmusicproxy.

After a bit of tinkering in the python, I have determined that the tags object IS in fact getting populated with appropriate data... But it doesn't seem to be getting into the file delivered to the client. I have to get to bed though... So I'll dig deeper tomorrow.

from gmusicproxy.

Hi,
I'll try to reply to each point/case you raised:

• it looks that players (included VLC) are not able to get the ID3 on a streamed content; upon download, it can be played with any player getting the metadata from the ID3 tag; VLC works out-of-the-box also for streamed contents because, as you focused in your second post, it gets metadata from m3u file;
• as long as I can see, the only way to get on-the-fly the metadata from a streamed content is to the shoutcast metadata standard (optional in gmusicproxy);
• today I fixed a couple of bugs in the code of gmusicproxy about the shoutcast support (I was I contribute of another user that didn't test enough...) and the http headers;
• I downloaded and tested Audacious today (no way I can install Amarok...): it is quiet stupid ignoring the filename of the playlist in the HTTP headers (content-disposition); it works if you add a prefix on the url like &format=.m3u; I can't fix this; I guess Amarok has the same behavior;
• if you want to locally download a playlist or mp3 file you should use wget with the --content-disposition option or to use curl.

from gmusicproxy.

OK, I can verify that with the latest bugfixes, Shoutcast support is working. However, it won't work for my needs: I need the metadata fields populated in Amarok populated so that other plugins (Like last.fm) work; The shoutcast protocol only seems to be populating the title.

It's surprising to me that players won't read ID3 tags from streamed content; How then do the internet radio stations stream their tags?

Also interesting, in investigating the downloaded MP3 files, ffprobe (From ffmpeg) can find metadata on the file, but mp3info says there is no ID3 v1 tag? Is this an error on mp3info's behalf, or are there multiple ways of storing the metadata?

from gmusicproxy.

Forget what I said about mp3info... Upon reading the manual, I find that it's only capable of reading ID3v1 tags, thus why it doesn't see our IDv2 tags.

Still curious about how m3u based internet radio stations are sending their tags though... Cuz those seem to work fine in Amarok (And elsewhere).

from gmusicproxy.

I've been reading about the various streaming options here: http://jicyshout.sourceforge.net/oreilly-article/java-streaming-mp3-pt2/java-streaming-mp3-pt2.html I share it more for future n00bs like myself that may stumble across this thread...

Interestingly, they state that there IS a method of encapsulating ID3 into the stream, but that nobody actually does... Do we?

The ShoutCast protocol is certainly more common, but bears the disadvantage of corrupting the audio frames, which has to be cleaned up by clients... On the other hand, the popularity of the standard means people are working around the limitation. Because of its popularity, we probably want to keep it around, but we should probably expand it to send metadata in more than just the title attribute.

I will continue familiarizing myself with these protocols, then take a stab at the code.

from gmusicproxy.

Another link for n00bs in the future, the ID3v2.3 documentation talks about the "Idea" of putting ID3 tags in a stream in section 4.19: http://id3.org/id3v2.3.0#Recommended_buffer_size

The entire discussion boils down to one sentence, "For applications like streaming audio it might be an idea to embed tags into the audio stream," and then proceeds to discuss considerations for the recommended buffer size in several situations... Not the most in depth discussion ever, but certainly a foundation to start from.

from gmusicproxy.

OK, I feel like I have invested more life into the ID3 tags issue than the task actually warrants, and my conclusion is that the problem is with the clients, NOT with your code, and my reasoning goes thusly:

• ID3v2 moved the metadata to the beginning of the file, to better support streaming. It also appears to support more frequent updates, but I can't find ANY evidence of ANY server doing so, and I can't find ANY tools that will create such a stream...
• GMusicProxy DOES include ID3v2 data, as is evident when downloading the MP3 file and inspecting it with ffprobe, and when playing the file locally. This SHOULD mean that the clients are RECIEVING the metadata the moment they open the stream... If they clients aren't USING it, that's not on GMusicProxy.
• Further, these results seem to be consistent with other servers and other clients around the internet... Although, very few people are actually talking about it, and so while I feel like I've invested a lot of time looking, it still FEELS like a solution SHOULD exist somewhere...

Eh, anyway, a task for a future n00b smarter than me... And I will agree to stop fighting it, and give up...

But there IS still a bug present... Shoutcast Support, as implemented, only uses the Title attribute, and NOT the Artist or Album attributes... But that's a separate issue, so I'll open a new bug report...

AS FOR THIS bug report.... I am closing it. If anyone has the ability to merge it with Issue 41, that would seem appropriate, as it is related and the links I provided will help anyone who stumbles across the issue better understand the nature of the beast.

from gmusicproxy.