Bugzilla – Bug 15821
Network interruption would leave "sticky" "File not found" message
Last modified: 2011-05-23 09:35:00 UTC
- SB playing music - rebooted router/access point - message showed up on Controller - message would go away on key press, but immediately re-appear - message would not go away by rebooting the Controller - message went away after I started a new track
Created attachment 6587 [details] reoccuring popup on various screens
Squeezebox Server-Status Version: 7.5.0 - r30234 @ Tue Feb 23 01:05:13 PST 2010 Hostname: squeezemywhs IP-Adresse des Servers: 192.168.0.120 Server-HTTP-Portnummer: 9001 Betriebssystem: Windows Home Server - DE - cp1252 Plattformarchitektur: 586 Perl-Version: 5.10.0 - MSWin32-x86-multi-thread MySQL-Version: 5.0.22-community-nt Anzahl erkannte Player: 1 Controller FW r8610
My strong inclination is that this issue is entirely server-side, and it was caught in a loop and sending out an endless string of showBriefly messages. I'm not of the mind that this is correctly assigned to me right now.
I still think this is a regression. This only started happening recently. I can easily reproduce it by restarting my router. I do this regularly, and have done so for about a year and a half, as my nice VPN pretty often loses its connection and wouldn't reconnect without the router being rebooted. Never had I seen the "file not found" issue until about two weeks ago.
The reasoning behind this change is that by default we disable it on any platform which would require manual configuration for iTunes integration to work anyway. The risk imho is minimal.
Forget my last comment - that was the wrong bug...
Possibly related to bug 15046?
QA to reproduce in a reliable way, and guess how common this is.
Estimate time
== Auto-comment from SVN commit #30393 to the slim repo by ayoung == == https://svn.slimdevices.com/slim?view=revision&revision=30393 == bug 15821: Network interruption would leave "sticky" "File not found" message Close stream from SbS to player when generating playerStreamingFailed() event after streaming no data. Just start playing next track when playerContinue event received in state PLAYING-TRACKWAIT.
The above is not a complete fix. The problem arises when a player reconnects (sets the 'reconnect' bit in the Slimproto HELO message) but had actually already received the complete stream. Unfortunately we cannot rely on STREAMOUT state to help us handle this, as STREAMOUT could be entered before all the data has actually got to the player. So the server (StreamingController) tries to stream the remains of the file, which is zero bytes, to the player. When end-of-file is hit (immediately) it generates an error because streaming zero bytes is often an indication of a problem with transcoding or remote source. It is necessary to generate an error because, in the normal non-reconnect case, a player will not generate a track-started event (nor STMd, etc.) for a zero-length stream. We need to devise a way to avoid re-streaming when the bytes-received counter is already at the end of the file, and just enter STREAMOUT state without causing the current playing track to be stopped prematurely.
== Auto-comment from SVN commit #8661 to the jive repo by ayoung == == https://svn.slimdevices.com/jive?view=revision&revision=8661 == bug 15821: Network interruption would leave "sticky" "File not found" message Force TinySC rebuild
*** Bug 15931 has been marked as a duplicate of this bug. ***
Comment 11 notes the remaining work that is okay for 7.5.x
Alan notes that player.source logs might be helpful
Was able to observe issue in real-time resolve itself. Fab4/TinySC with 4 IP3K players connected running r8661. Here's what I saw: 1. Player playing MP3 file showing Now Playing info. 2. Player would have "Unable to connect to server" message. 3. Player would then display File Not Found message, but resume playing of MP3 file. 4. File Not Found message disappears 5. Player screen returns to normal and shows appropriate Now Playing info. This happened for 3 of the 4 players one after the other, so I was able to observe this repeatedly. Given the above, it does appear that some sort of interruption in the player's communication to Fab4 instigates this chain of events.
Created attachment 6687 [details] Messages log file from TinySC for Comment 16 I grabbed the Messages log file immediately after Comment 16 occurred.
Any thoughts about why one configuration might see the symptoms in Comment 16? I have two almost identical Fab4/TinySC setups running: 1. Fab4/TinySC r8661 with 4 SB3 and Seagate Expansion 2TB external powered USB 2. Fab4/TinySC r8661 with 2 SB3, 2 Booms, and Hitachi XL1000 1TB external powered USB. All Fab4 units are MPQ, on the same wireless network, physically next to each other, and playing Harry Potter Audio CD MP3 tracks continuously. Each player on a Fab4 plays different tracks -- player #1 plays HP book 1, player #2 plays HP book 2, etc. Setup #2 is seeing the Comment 16 symptoms every 15-30 minutes on multiple players, while Setup #1 has never seen it (or maybe #1 has when my back was turned).
It is very difficult to speculate. In a previous wireless setup at home I had a baby that was mostly connected at 90% signal strength but which would sometimes fall of the network completely. Moving it 15cm caused it to have 70% strength and virtually never fall off the net. Or, if the interruption is triggered externally, by the access-point for example, it could simply be a timing issue.
Created attachment 6731 [details] Untested patch for remaining issues Just stashing this here for the time being.
Created attachment 6747 [details] Updated patch
The changes necessary for the final fix are too involved for a minor release, and the remaining issue is pretty minor anyway.
== Auto-comment from SVN commit #30529 to the slim repo by ayoung == == http://svn.slimdevices.com/slim?view=revision&revision=30529 == Fixed bug 15821: Network interruption would leave "sticky" "File not found" message The contents of the $seekdata hash returned by the getSeek*() methods of various protocol handlers is generally opaque to the caller. The special boolean value 'streamComplete' is used to indicate that the requested seek would have been at or beyond the end of the stream and is therefore denied. The caller is required to check for this value. This mechanism allows the StreamingController to detect that a playerContinue() has been invoked (as the result of a reconnect after a network interruption) when the full stream has already been received by the player and therefore it can just let the track play out. The complications in this change mostly arise from coping with a stream restart in a stream that was already the subject of a seek, which was not handled properly before.
Closing. Please reopen if seen again.