Bugzilla – Bug 3551
Radio Tune In adds stream twice
Last modified: 2008-09-15 14:38:25 UTC
When playing a radio stream via the "Radio Tune In" the stream is added twice. For MP3's the track appears in the playlist twice but for some other stream (rstp) is causes the track to start and immediately stop.
Can you provide the mp3 link you're pasting in the Radio Tune In box? Are you sure it's not a playlist that contains 2 items?
Created attachment 1264 [details] Trace file
I have attached a trace file showing the problem. I started slimserver then went to Radio Tune In and enter the url http://vruk.ic.llnwd.net/stream/vruk_vr_hi. At "2006-06-15 18:09:14.5328" the first stream is opened and then again at "2006-06-15 18:09:17.7211". Let me know if you need anymore information.
I can't duplicate this. Please try with 6.3 from svn or tonight's nightly and see if the problem still occurs.
Using 8002 it is still happening. I am using WinXP and IE and have just tried FireFox and it doesn't happen. Adrian (AlienBBC dev) thought it may be the browser causing it. He doesn't see it as frequently as me but he is using *nix.
I see this too - I believe it is due to the browser sending two requests for the station. Could this be due to the javascript in the tune in page causing the get to be sent twice? Happens on IE6: --d_http_v shows the following: 2006-06-15 20:26:50.0756 More to send to 10.0.0.1 2006-06-15 20:26:50.0772 No more messages to send to 10.0.0.1 2006-06-15 20:26:50.0786 No segment to send to 10.0.0.1, waiting for next request.. 2006-06-15 20:26:53.6820 reading request... 2006-06-15 20:26:53.6827 HTTP request: from 10.0.0.1 (HTTP::Daemon::ClientConn=GLOB(0xa2b1a80)) for GET HTTP/1.1 /tunein.html?p0=playlist&p1=play&player=82%3A5f%3A94%3A9b%3Aca%3A73&p2=http%3A%2F%2Fvruk.ic.llnwd.net%2Fstream%2Fvruk_vr_hi 2006-06-15 20:26:53.6847 HTTP parameter p0 = playlist 2006-06-15 20:26:53.6853 HTTP parameter p1 = play 2006-06-15 20:26:53.6858 HTTP parameter player = 82:5f:94:9b:ca:73 2006-06-15 20:26:53.6869 HTTP parameter p2 = http://vruk.ic.llnwd.net/stream/vruk_vr_hi 2006-06-15 20:26:53.6884 processURL Clients: 192.168.1.101:28712 10.0.0.1:2615 192.168.1.102:43031 2006-06-15 20:26:53.6941 End request: keepAlive: [2] - waiting for next request on connection = Keep-Alive 2006-06-15 20:26:53.6952 reading request... 2006-06-15 20:26:53.6956 Client at 10.0.0.1 disconnected. (half-closed) 2006-06-15 20:26:53.6974 Accepted connection 1 from 10.0.0.1 2006-06-15 20:26:53.6996 reading request... 2006-06-15 20:26:53.7004 HTTP request: from 10.0.0.1 (HTTP::Daemon::ClientConn=GLOB(0xa1569ec)) for GET HTTP/1.1 /tunein.html?p0=playlist&p1=play&player=82%3A5f%3A94%3A9b%3Aca%3A73&p2=http%3A%2F%2Fvruk.ic.llnwd.net%2Fstream%2Fvruk_vr_hi 2006-06-15 20:26:53.7022 HTTP parameter p0 = playlist 2006-06-15 20:26:53.7029 HTTP parameter p1 = play 2006-06-15 20:26:53.7034 HTTP parameter player = 82:5f:94:9b:ca:73 2006-06-15 20:26:53.7041 HTTP parameter p2 = http://vruk.ic.llnwd.net/stream/vruk_vr_hi 2006-06-15 20:26:53.7054 processURL Clients: 192.168.1.101:28712 10.0.0.1:2615 192.168.1.102:43031 2006-06-15 20:26:53.7102 End request: keepAlive: [1] - waiting for next request on connection = Keep-Alive
Weird, I'll look at the JS. Wouldn't the second 'playlist play' just overwrite the first one in the playlist though?
might try the refreshStatus() sub from common.js instead of INCLUDEing reloadStatusFrame.html in tunein.html This avoids resending the query params and was causing similar problems with randomplay at one point.
Fixed, just had to change the type of the input button to "button" instead of "submit" so it would only submit via the javascript.
Merge into trunk, and any other skins that might need the same fix?
Trunk didn't look the same, but I didn't test. Can you check it out?
I believe trunk just uses EN, and I'll put it on my list for verification :)
This fixes the problem for me, thanks.
This bug fix is now part of a released version, and so has been marked closed. If you are still experiencing this problem, please reopen the bug.