-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Grundig Sonoclock 890A-Web fails reading the station list #137
Comments
And it turns out to be "complicated"... The good news: It's not the ID. This device breaks on the station list if:
Even when stripped down, it fails playing the station, because it does not call
And it expects a return of this kind with all the additional values that need to be missing in the first list:
Since this "search" is not implemented yet, it fails with a 404 and results in "network error, please retry". As soon as this reply is there, it issues ANOTHER call get the final channel URL within a special Content-Type. It seems weird, that this call is NOT protected by any token, so one could try to iterate through the station numbers. I have yet to try, if this dynamic URL, that is submitted by the previous call can be exchanged against the true station URL, successfully skipping the last step:
Given this, it does not wonder that encoded characters within the station name are not decoded for the display either. So a station
displays as
Since the reply is marked as UTF-8, the character encoding would be necessary for just " <, &, >" and might be superfluous by XML definition. I guess this would need a big addition that is likely to break things for all others. :-( Btw. What was the idea about prefixing the UID with additional characters? Aren't GUIDs meant to be "globally unique" by definition? Any current GUID creation routine is guarranteed to not create any duplicate. |
And more complication, but with some brute force I got it working. I could have noted in the previous post, that the ID is truncated to 32 characters by my device before it is placed into the search. Formatted UUIDs are too long, adding a prefix does not make it better. If I am forced to use UUIDs and I'm forced to use a prefix, then I have to shorten the URL. I did this, by converting the UUID string into a real hex number (32 byte as string, 16 byte as binary) and then base64 encode that -> 24 characters for the ID + 3 for the prefix -> 27 characters in total. That easily fits into the 32-character limit of my device. This requires importing the base64 library. To encode and decode the UUID on the fly, I had to pimp two functions in
and
I added a new function in
and I added a case to get this called within
You might note the additional parameter
Ah, yes - I faked the This made my code work for the "Grundig SonoClock 890A", at least with the RadioBrowser stations. I'm still thinking about how to handle This certainly does not make a good pull request by now, but eventually someone can still comment about it if/how this eventually could enhance the current codebase. Btw: I stumbled over a possible bug in The "search" functions use unencoded search arguments too. Might break easily. |
Some final tweaks: The entitiy decoding in
After setting some defaults in case a value was not defined, my device now accepts the bookmarked entries too. It definitely does NOT like empty tags:
I still could need some queries from other devices to confine all those changes to my model and not disturb others... |
I successfully convinced the above radio to communicate with YCast. It walks through the menus and directories that are fetched from "radio-browser.info" and it displays the configured stations.yaml.
But on every level that lists the actual station, it only displays a "communication error, please retry". It's the same when tryng to list the configured favorites.
I verified the communication with wireshark and the radio gets a station listing and confirms the recipt. It obviously does not like the data.
Cross checking with the original data captured from a communication with "grundig.radiosetup.com" (which IS vTuner), I see some content differences:
Original:
YCast version:
While it should not harm to send more information, it seems a little odd to send the
StationId
as a string instead of the original integer. Due to the prefix it disqualifies as a GUID.Is it granted that all(?) vTuner clients accept a station id as 39-character string? No problem report so far on this level? I did not find any reports in the past issues. But I don't see any "Grundig" devices either.
The different XML encoding "should" pose no problem as long as the client is sufficiently XML compliant.
Maybe the added parameters
&fver=1&ven=grn6
have a special meaning in preparing the output for that device.But then ... the
StationId
does not seem to carry valuable info in this collection anyway. It IS contained in theBookmark
URL and will get the right stream when queried from a saved entry. At least my device has no option to search byStationId
, so I think it is dumped anyway.The text was updated successfully, but these errors were encountered: