Art for some radio streams not updating #103
Comments
distler
changed the title from
FIP Radio art not updating to Art for some radio streams not updating
on 7 Jun
serverbaboon
commented
on 7 Jun
The content you are editing has changed. Please try again.
Looks like FIP doesn't have any metadata, the MPD status for that stream gives {'pos': '0', 'file': 'http://direct.fipradio.fr/live/fip-midfi.mp3', 'id': '3'} While the KCRW does seem to. {'id': '6', 'pos': '0', 'name': 'KCRW E24', 'file': 'http://kcrw.streamguys1.com/kcrw_192k_mp3_e24_internet_radio', 'title': 'Little Dragon - Celebrate'}. Can I ask do you webscrape the radio website most of the time to get the artwork or have you found other Radio stations besides RP who make it easy? |
The content you are editing has changed. Please try again.
Oh. That's easy. The metadata (in JSON format) is available at this URL. Parsing it to obtain the album art is almost trivial:
The rest of the metadata (song title and artist) is there, too. If there were a way to plug that into |
The content you are editing has changed. Please try again.
Perhaps a good solution would be to generalize (replace or augment) All of the fields would be optional and any which are absent would be replaced by the corresponding in-band metadata (or the |
serverbaboon
commented
on 7 Jun
The content you are editing has changed. Please try again.
Thanks, your ruby looks better than my python scratchings, I have found that it can be such a pain tracking down the data for each station, so far xml for RP, json for Linn and webscrape for Naim an d most annoying for me no metadata on BBC streams. I think (will have to look) upmpdcli passes the url to MPD which does the decoding and upmpdcli pulls back from MPD that current playing status and if MPD does not have artist and track in the file field (for http radio stream) then it cannot trigger the script as there is never a change. I have mostly working Python script that will do a gracenote lookup for none artwork publishing stations, however since it checks the current mpd song status it still fails as stations that don't have the metadata in the stream. |
The content you are editing has changed. Please try again.
Finding the URL for the metadata is pretty challenging. But, when I find it, parsing is usually easy (it's either JSON or XML).
That's certainly the symptom I was seeing. Which was why my first suggestion was simply to have an option to re-fire the script at some user-defined interval. As to obtaining the rest of the metadata, here's a trivial modification to the above script, which returns a JSON object with the metadata about the currently playing song
|
serverbaboon
commented
on 7 Jun
The content you are editing has changed. Please try again.
mmm suppose it is a question of what sort of time, not short and not too long that half the song has the wrong image. |
The content you are editing has changed. Please try again.
In the case of the above stream, I can tell you exactly when to refire the script:
The For other streams, I might not be so lucky and might have to guess (say, something like |
serverbaboon
commented
on 7 Jun
The content you are editing has changed. Please try again.
Dynamic refresh times based on the return values, interesting , bit beyond my fumblings. I think you maybe lucky on the FIP json data to get the running time Linn Radio and Radio Paradise don't seem to have it. I'll wait to see what medoc says with interest, he looks busy at the moment, looking at the repositories. Now if only the BBC opened up their meta data...... |
The content you are editing has changed. Please try again.
Just trying to be as flexible as possible. The script could just as well return the same number each time (for streams that don't provide the relevant information).
If they do, let me know. I would love to add that information. :-) |
The content you are editing has changed. Please try again.
Hi, It's very nice to have somebody else do the thinking, I would very much like this to happen more often ! You are right about how things currently work: upmpdcli polls mpd for stream metadata (mpd extracts it from streams where it is embedded, look up Icy-Metadata for more info). If the artist or title changed, it fires the art script. Some radios do not embed Icy-Metadata (this does seem to be the case for the FIP stream), so the script is only executed once, when starting up. Your idea of a script which would retrieve all metadata and also send back an update interval is a good solution to this issue. I am a bit dubious about JSON though. It's not a problem for the C++ code, because it already uses a JSON package for talking to the streaming services modules. However, the quoting rules will be a bit more complicated than those for the upmpdcli config format (which only needs escaping newlines). This could be an issue for someone writing a shell script. OTOH any radio providing this data is probably going to do it in JSON... (thinking aloud...). So, yes, JSON. Adding this to the TODO I guess, it should not be very complicated, I hope I can do it soon, it's a nice idea. |
distler
commented
29 days ago
The content you are editing has changed. Please try again.
Obviously, the in-band Icy-Metadata, if present, should take precedence.
I'm not wedded to JSON output. I can replace
with
I just assumed that, on the receiving end, JSON would be easier to parse. |
The content you are editing has changed. Please try again.
JSON is fine I think. I wrote a quick implementation, seems to work, but I'd appreciate some testing. Doc here: https://www.lesbonscomptes.com/upmpdcli/pages/upmpdcli-manual.html#radio-definitions The git libupnpp seems to crash, use 0.15.2 for now (this has nothing to do with the radio thing). |
distler
commented
27 days ago
•
The content you are editing has changed. Please try again.
I don't recommend the version, above, of the Ruby script that I wrote. Here's one which doesn't rely on the order of the conversion from a hash to an array of values (lousy programming practice):
(It also converts the Artist and Title metadata from ALL CAPS, which is more pleasing to my eyes.) |
The content you are editing has changed. Please try again.
Ok. I replaced it in the manual. |
distler
commented
27 days ago
The content you are editing has changed. Please try again.
As to testing, I'm sorry to say that I'll be traveling for the next 3 weeks (leaving in an hour), and won't be anywhere near my Rpi streamer. Hopefully someone else will be able to provide more timely feedback. Thanks for implementing this! |
The content you are editing has changed. Please try again.
No hurry of any kind really, it will still be there in 3 weeks :) |
serverbaboon
commented
25 days ago
The content you are editing has changed. Please try again.
Just to be clear in my head if we cannot return a reload time do we return a null value or not return the key value pair at all? { |
The content you are editing has changed. Please try again.
Don't set it (the default will be 10S). But use the code I just pushed because things did not work well with reload not set in the previous version. Of course, you can also set it to the default of 10S or any value of your choice (not too small !) |
serverbaboon
commented
25 days ago
The content you are editing has changed. Please try again.
After struggling trying to understand Ruby , whatever FIP is doing with their metadata and my beginner status I managed to get some success. I ended up using another FIP station as the one Jacques uses goes into periods of no metadata update for some programs or podcasts which confused me for a while. I said some success ... On my older windows Linn Kazoo artwork, artist and title all display correctly. I attached a sample from the log, I emailed you the full log, one thing I noticed as that the reload calc needs some allowance for the radio station metadata update on the website as you will be able to see the are several calls of the script running returning a negative reload time. I guess maybe adding 10 secs to the calculated reload time in the script is required before returning the value. I noticed that Jacques does add 1 in his script. I did notice that Kazoo updates the picture for the current playing track before the FIP website does :-)
|
distler
commented
24 days ago
The content you are editing has changed. Please try again.
The early version of the script had several defects. The last version that I posted corrects those and
I suggest trying that version of the script instead of the one you're using. You're right that FIPS doesn't provide useful metadata for their late-night (Paris time) shows. In those cases, the current version of the script returns nothing (so the
I think the current version of the script also addresses this timing issue, but you could try changing the Again, apologies that I am traveling and can't help in the testing myself. |
The content you are editing has changed. Please try again.
I just pushed an update to the c++ which guards against very small or negative reload times. By the way, I've known for some time that there is an issue in upplay about updating the current song metadata, I think mostly for the 1st track played. I intend to look into it, this has nothing to do with the radio art script, but may explain the upplay issue above. As for mixing artist and title, I have no idea what could do this... |
distler
commented
24 days ago
The content you are editing has changed. Please try again.
Also, I suppose it would be good to test that this all works with radio stations which have in-band metadata, e.g.:
|
serverbaboon
commented
24 days ago
The content you are editing has changed. Please try again.
@distler My PI does not have Ruby installed so using Python as I am trying to learn it, I am afraid that learning Ruby on top of Python and also a little French (Metadata) could actually cause important brain function to shutdown. :-). Hadn't realised that Radio Paradise also published the timings, that would have saved some pain. Found FIP electro station does provide constant metadata, however may switch to the Radio Paradise testing. @medoc92 |
distler
commented
24 days ago
The content you are editing has changed. Please try again.
Not that I don't like the idea of someone rewriting these in Python, but being able to compare the output with the (known to work) Ruby version might prove useful. |
serverbaboon
commented
24 days ago
•
The content you are editing has changed. Please try again.
mmm ok. I have had string issues before with Android not liking a url string but windows was ok, Turned out that the Linn Radio art urls needed some spaces converting to %20 before Android would accept the url. |
serverbaboon
commented
24 days ago
The content you are editing has changed. Please try again.
No difference with the Ruby version, I used the FiP Electro station and same symptoms. I will try and get Kazoo to produce some logs. Think it might be charset/string related going off a previous issue but not sure. http://direct.fipradio.fr/live/fip-webradio8.mp3 |
serverbaboon
commented
24 days ago
•
The content you are editing has changed. Please try again.
Regarding the -ve or 0 value reload times the FIP meta data has the next track details listed, so amended my script as below, I have shoved a couple more variables than necessary as I am still trying to work out what to do with the FIP Paris variable metadata with multiple "levels" and deal with a couple of error conditions. (nothing really to do with the Kazoo issue though) Anyway the current playing track is '3' and the next track is '4'
|
serverbaboon
commented
20 days ago
•
The content you are editing has changed. Please try again.
Ignore the above, it actually relies to much on someone being consistent in the way they publish their metadata. It seems to be foolish to display the last three tracks, the current playing track and the next track to then for periods of the day not bother updating the next track. Infos non disponibles....groan. backup to looping or using position '3' and adding 15 for the reload time. WIll try and contact Linn see if they will look at it, there was a recent fix to Kazoo that looks suspicious, they at least might tell me how to generate the logs correctly as they are not generating for me. They fixed this in a recent update and my older working Windows does not have the fix. |
serverbaboon
commented
19 days ago
The content you are editing has changed. Please try again.
Definitely an issue with the latest version, I have just updated a working windows version to the latest version in the Windows App Store and it has now stopped working correctly. So if you haven't already updated to the June Release 4.11.229.0 (andriod ) or 4.11.228.0 (IOS) then DON'T. I have emailed Linn from inside the Kazoo Android Application to see if they will look at this. |
serverbaboon
commented
17 days ago
The content you are editing has changed. Please try again.
I have another Radio station where this no artwork, should I pass back a null value or perhaps the station logo address (from the conf file) ? |
The content you are editing has changed. Please try again.
I think that returning an empty string should work. Upmpdcli will then use the station static art automatically. |
distler
commented
17 days ago
The content you are editing has changed. Please try again.
Just on principle, I would not return anything for a particular field if the radio station doesn't supply a value for it. (That is, |
The content you are editing has changed. Please try again.
You are right in principle, but I was worried that the c++ code would discard the whole packet. Actually it doesn't so you are also right in practise :) |
serverbaboon
commented
17 days ago
The content you are editing has changed. Please try again.
I have had a response back from Linn suggesting that the latest versions of Kazoo indeed have an issue with open home renderer's after about version 4.8.1200 (on Windows at least). They have no timetable for a fix. I have not tried Lumin on the ipad. So while the artwork can update there may still be an issue with Artist and Title until Linn fix Kazoo or Bubble get on board for and support Dynamic for metadata perhaps the one person using the feature on Android :-). |
distler
commented
7 days ago
The content you are editing has changed. Please try again.
Well, I'm back. Looks like in my absence version 1.2.15 was released, including this functionality. In my (limited) testing (I really just got back this afternoon), it seems to work well. The only defect I see is that (using Lumin and Linn Kazoo) the title is displayed twice
rather than (as I was expecting): title + artist
On closer inspection, the latter appears fleetingly, when the song changes, but is quickly replaced by the former. Very strange ... |
serverbaboon
commented
7 days ago
The content you are editing has changed. Please try again.
Another interesting thing is occasionally FIPS seems to slip a 'name' into the Radio stream. So I am playing FIPS Electro and MPD has this. {'id': '15', 'name': 'FIP webradio8 back', 'file': 'http://direct.fipradio.fr/live/fip-webradio8.mp3', 'pos': '0'} My script in debug mode produces: and for the sake of completeness the JSON output of Distler's script (url modified)
Kazoo displays the artwork and briefly the Artist and Title then Displays Radio, the 'name' field from MPD and does not update the artwork after that. It looks like: |
serverbaboon
commented
7 days ago
•
The content you are editing has changed. Please try again.
Just checked another non metadata metastream for a Hi Res Flac stream for Jbradio2 it has the name tag http://209.126.66.166:10999/flac' This gives the below from an MPD Status check Executing my script (horrendous webscrape) pulls back the artwork Title and Artist (no time) giving a json output of {"reload": 10, "artist": "Blaudzun", "artUrl": "https://jbradio2.ca/images/covers/Heavy%20Flowers.jpg", "title": "We Both Know"} Kazoo briefly displays everything correctly , then Changes to displaying Radio Is this UPMPDCLI taking the 'name' entry from MPD and changing its status to a Radio Station for a control client? Maybe if a metascript is specified it should take precedence over the mpd data? Not sure if this is expected behaviour but if you change the radio station without stopping the previous stream I am not sure the script is executing, it certainly does not seem to update artwork. I doesn't help when we know Kazoo currently has some ohradio issues non linn ohome players. |
The content you are editing has changed. Please try again.
Hi, I have added a preferScript parameter to the radio block: it says to ignore Icy metadata (from mpd) if we have a script.
This seems to fix the fleetingness of the real metadata for me. In other news, I am in the process of migrating all my projects to a different server: The onsite interface is much less convenient than the one on Github, but it's in Europe and so closer to my heart. For the moment, I'll push updates to both github and opensourceprojects.eu, but the primary is already the European one. |
distler
commented
6 days ago
•
The content you are editing has changed. Please try again.
Wow, getting in on the ground floor ("browse projects" yields 3 pages of entries, of which Do you want bugs reported here, or do you want to move your bug-tracking to opensourceprojects.eu as well? |
The content you are editing has changed. Please try again.
Yes I know :) but the admins affirm that the site is alive. In any case, it's easy enough to move a git repo around if things don't turn out well... I was looking for a European github, and did not find much, which is a bit of a shame given the amount of open-source work which is actually done in Europe. opensourceprojects.eu is the closest I found. If you want to give the ticket manager a try, you can have first post :) But the last thing I want is inconvenience people. Having to clone from a different repo seems reasonable, but if the issue tracker is too bad, it becomes a problem. We'll see :) |
serverbaboon
commented
5 days ago
•
The content you are editing has changed. Please try again.
Ok the latest version stops the brief appearance before reverting but now back to I wonder if Kazoo can handle Artist in the Meta? the ohome website only says the below are guaranteed to be available.
Trying to understand where the name field in the stream that appears in the upmpdcli to see what happens if 'name' is sent back with artist value, but head now hurts. However I have changed my scripts to return my title in the same format as MPD does so my script returns: ` ` If only Linn would fix Kazoo to give us a known starting point. |
serverbaboon
commented
5 days ago
•
The content you are editing has changed. Please try again.
Sorry forgot to emphasise nothing needs to change until Linn fix Kazoo as my old Windows version of Kazoo works correctly Title Was just saying that to get Kazoo on my tablet or phone to give useful info I have amended my scripts to give an MPD/ICE Meta style title field. Interestingly BubbleDS only displays title ( never mind no artwork) so maybe the ohradio is not as complete as Kazoo's. |
distler
commented
8 hours ago
The content you are editing has changed. Please try again.
appearing and then being replaced by
This happens for the first song played. The subsequent songs all appear immediately as
I'm a little mystified as to why the behaviour changes from the first song to subsequent ones. But that does seem to be reproducible (and happens with both Lumin and Kazoo CPs) |
distler
commented
8 hours ago
The content you are editing has changed. Please try again.
Hmm. I think this is a bug (coincidentally in both Lumin and Kazoo). If you tap on the Album Art in Lumin, it goes to full-screen and displays both Title and Artist correctly. So it's definitely receiving the correct information. Unfortunately, in the standard views (aside from that full-screen one), it's displaying that information incorrectly. I don't think there's anything you can do to fix this. I wish Lumin had a public issue-tracker... |
distler commentedon 6 Jun
The content you are editing has changed. Please try again.
It's not clear to me that this is a
upmpdcli
problem, or an irresolvable problem with the MP3 stream.The
artScript
fires once, when I start playing the stream, and then never again. So the song art displayed is the one associated with the first song playing when the stream started.The result is the same in both Kazoo and Lumin, so I think it is not a CP problem.
Other radio streams, like
do update the song art correctly, so my best guess is that
upmpdcli
is treating the FIP stream as one, infinitely-long, song.A possible workaround would be a configuration option to re-fire the artScript at a user-defined interval, even if
upmpdcli
"thinks" the current song is still playing.