Bugzilla – Bug 4110
Incorrect display with browser refresh after adding Internet Radio station from playlist
Last modified: 2008-12-18 11:12:12 UTC
Browser = Firefox Skin = Default To help with verification, I have a playlist of internet radio stations that I will attach to this bug report. I'm not sure if "skins" is really the correct component, as the problem seems to begin with a long delay after adding an internet radio station from a playlist to the "now playing" list. Steps to repeat: 1) Add the attached "Internet Radio Favorites" (playlist of internet radio stations) and rescan playlists 2) Do Browse, Playlists, and choose "Internet Radio Favorites" 3) Next to "The Best Hungarian Jazz Station", click "Add to Playlist". This is an ogg stream, but the problem seems to occur with MP3 streams as well. 4) A long delay follows. This delay does not occur with 6.3.1. After a couple of seconds, click the browser refresh button. 5) Get an incorrect display. The results of this seem inconsistent, but I usually get the border between panes disappearing, with the right pane taking up the entire client area of the browser. Sometimes I can get the correct display back by clicking the browser refresh button multiple times, but other times I cannot. I am going to leave the priority alone, as I am a customer. But I did move severity up one notch.
Created attachment 1534 [details] Playlist of internet radio stations for use in "Steps to repeat"
I can reproduce this following the reporter's instructions. Note the web UI should be used, not the player UI. However, perhaps my machine is faster than the reporter's, but I had to act very fast to click 'refresh' before the radio station appeared in the right pane and everything worked normally. It is critical to click during the mysterious delay between clicking 'add to playlist' and when the station appears in the playlist. Andy Grundman, I thought I'd assign this to you due to it mentioning a radio station, but if it's really in someone else's area of expertise feel free to assign it on or back to me. Andy Connors, I take this bug very seriously, but it does not match our guidelines for a "major" bug, so I changed the severity. If it happened with every radio station, regardless of whether "refresh" was clicked, it would qualify for "major".
Created attachment 1535 [details] Capture of display after waiting 30 seconds for station to show up
I'll take a look, but please also see bug 4092. You should avoid putting multiple radio stations in a single playlist. Either use 1 station per playlist, or try the MyPicks plugin.
I am also seeing this issue. In my opinion the current state of slimserver with respect to this issue is a step backwards. I would think there are lots of customers having playlists containing multiple remote ULRs. How are you planning to deal with all the customers experiencing that something that has worked perfectly before suddenly stops working?
Using the "Radio tune-in" feature, I tried the same stations I was having problems with above. I saw the same problems. Based on this result, I'm not so sure it has anything to do with having multiple stations in a single playlist.
Do the stations play fine at least, when using Tune In? The only problem is the web getting messed up?
looks as if, somehow, the browser starts seeing the html as plain text
Andy, they play okay (after about a thirty second delay) using radio tune-in or from the multi-station playlist - either way. It's just the corrupted web display and the long delay that I'm concerned with. I've seen several variations of the web display corruption. One variation is only showing a single pane (right side only) with no divider. A second variation is like the attachment I posted. A third variation looks like a dead ringer for the "Light" skin.
To diagnose why there is a long delay, run with --d_scan --d_parse --d_directstream.
My comments below all refer to the web UI. My habit in the past (for whatever silly reason) has been to click the "Add to Playlist" button in the left ("browse playlists") pane, then click "Play" in the "now playing" list in the right pane, or the play button on the remote. However, if I just click the "Play" button for the station in the "browse playlists" pane, the station plays almost immediately. It doesn't show up in the "now playing" list on the right until after about a 30 second delay though. After the delay, I sometimes, but not always see a garbled display like in my attachment above. But if I hit "refresh" before it updates by itself, I always see a garbled display. Referring to my comment number 6 above, doing a "radio tune-in", the station plays almost right away. It just doesn't show up on the "now playing" list until about 30 seconds later. I should have been more clear on that. This appears to be purely a UI problem, not a problem with tuning in internet radio stations per se. Do you still want to see logs with those debug options enabled?
the delay after using tune-in is becuase the radio tune in page doesn't trigger a refresh of the now playing pane. The 30 second delay is the time for an automatic refresh. There is a mechanism to do the refresh, but it's for the onclick event. This means it may only work if the submit button is clicked. If you simply paste the url and press enter, this may bypass teh onclick. Just to be clear on any issue due to this, are you pressing enter or clicking the button?
Also note that the URL is scanned by the server before it is added to the playlist, so it won't show up right away anyway.
I just tried this experiment with clicking on the button and pressing Enter in "Tune-in". Using both Enter and clicking the button, I had a problem with the long delay before the station info was displayed. This delay is only a fraction of a second in 6.3.1.
*** Bug 4235 has been marked as a duplicate of this bug. ***
*** Bug 4383 has been marked as a duplicate of this bug. ***
Are you still working on this one, Andy? Is there anything I can do to help?
Ping! -- Chris O at Wallace's computer.
Created attachment 1924 [details] Slimserver garbled screen showing HTTP header. I have been trying to get a better handle on this bug. I have an interesting screen capture. This is backed up by an etheral capture file for the transactions and a debug log of slimserver for the same error. The curious part of this display is the display of HTTP header. This header is at the start of a TCP packet and the only way this should happen is if the "Content-Length" field was wrong on previous packets. I have checked the previous packet and they look OK. This makes me there is a possibility this is a Firefox bug. To check this possibility I tried Opera but I haven't been able to get the same sort of corrupted display with Opera. If wanted I'll supply the Ethereal log or a text printout of the log
This bug has flown under the radar for a while. It's a common issue and is quickly reproducable, and is a catastrophic UI failure. It strongly affects customer experience and requires some attention. Should the priority be elevated? Should it be assigned to 6.5.3?
cc'ing Andy to see if he has any additional info
one possible solution could be to feed the radio station play command through an xmlhttprequest separately from the status refresh request. This is a better fit with the current state of 7.0, but 6.5.3 is not without some level of ajax so I could try a few ideas on the tune-in page. If I get something that works, we'll have to get a list of all points where it can be used.
no dice for me. it just infects the background request in much the same way. firebug reports an syntax errors and what I see is the raw html again.
I'm worried there may be a bug in the HTTP server code here. I'll take another look at it.
Fixed in change 12113
Note with this fix, that the playlist frame will refresh 5 seconds after loading, to give the URL time to be scanned and loaded into the playlist.
Thanks guys! Is this fix for 7.0 only, or will it be in 6.5.3 also?
Both.