Bugzilla – Bug 14326
Facebook/Flickr photo saver gets stuck
Last modified: 2010-04-08 17:24:55 UTC
When using the Facebook photos option for the "when stopped" screensaver, the images stop updating. Most easily repeatable case is when the screensaver is active and the player gets an update notice. I see that the photos stop, and when I touch the screen, it then shows the update notice. More recently, after sharing a song on facebook, I also noticed that the photos won't update.
Kevin: is this error still reproducible on production sn?
Yep: i was able to repo it. Ben is this yours to look into?
Not mine. Don't know whose, so tagging with bug_meeting
James didn't try with slideshow, only with screensaver. James estimates 10 minutes.
Tom to look and see if this is doable for 7.4.1
Is this still an issue? I've recently fixed some of the IV oddities.
I think it is. I still know when a firmware update is waiting as I seem to think the same pic has been showing for a long time. I'll do a specific test this evening.
Thanks Kevin. The problem is my latest changes to the ImageViewer didn't make it to any firmware yet - the build host is somehow not working. You'll probably need to test _after_ the next firmware update (r8489 or later).
ohhh....KD...she stole the show at the opening ceremony. We have the whole thing recorded for that alone. Tho for me, I was melting from the light show very early on. Shear brilliance, and a perfect example of the 'support' role that I love so much :) we will most certainly have the tv going. no fear. what I forgot to bring up...practise the avoidance of "guys" :) I hope you will choose to come early (4:30 to 5 is fine if you want to be ahead of hockey). I look forward to having some time prior to the rush and it will be nice for the puppies to get to know each other. My folks may or may not bring their dog. He's often happier being left behind lately. -k
Thanks Kevin, that last comment, ahm... forget it. I've set my screensaver to be using Facebook. Though I'd assume Flickr or some other ImageViewer based screensaver would behave the same. Let's see what happens.
Ok, this morning the screensaver was stuck. Unfortunately the log file is useless, as it's filled with the following lines: Feb 16 06:48:35 squeezeplay: WARN applet.ScreenSavers - ScreenSaversApplet.lua:222 A screensaver is already active - ignoring activate request. Feb 16 06:49:06 squeezeplay: WARN applet.ScreenSavers - ScreenSaversApplet.lua:222 A screensaver is already active - ignoring activate request. Feb 16 06:49:36 squeezeplay: WARN applet.ScreenSavers - ScreenSaversApplet.lua:222 A screensaver is already active - ignoring activate request. Feb 16 06:50:06 squeezeplay: WARN applet.ScreenSavers - ScreenSaversApplet.lua:222 A screensaver is already active - ignoring activate request. Feb 16 06:50:36 squeezeplay: WARN applet.ScreenSavers - ScreenSaversApplet.lua:222 A screensaver is already active - ignoring activate request. Feb 16 06:51:06 squeezeplay: WARN applet.ScreenSavers - ScreenSaversApplet.lua:222 A screensaver is already active - ignoring activate request. Feb 16 06:51:36 squeezeplay: WARN applet.ScreenSavers - ScreenSaversApplet.lua:222 A screensaver is already active - ignoring activate request. Feb 16 06:52:06 squeezeplay: WARN applet.ScreenSavers - ScreenSaversApplet.lua:222 A screensaver is already active - ignoring activate request. Feb 16 06:52:36 squeezeplay: WARN applet.ScreenSavers - ScreenSaversApplet.lua:222 A screensaver is already active - ignoring activate request. Feb 16 06:53:06 squeezeplay: WARN applet.ScreenSavers - ScreenSaversApplet.lua:222 A screensaver is already active - ignoring activate request.
Reading the code from where this message comes: -- In some situations the timer restart below tries to activate an SS when one is already running. -- Example: Blank SS for soft power off while in Diagnostics (i.e. an applet not allowing SS). -- This causes the backlight to turn on again after 10 seconds. #14986 if self:isScreensaverActive() then log:warn("A screensaver is already active - ignoring activate request.") return end Is something wrong with the ImageViewer screensaver causing repeated triggering of the screensaver?
Created attachment 6526 [details] my log section of my log. I'm not sure of the exact time when it stopped. However, there is a wireless timeout as well as some of the same messages about the applet already being active. The last line is when I backed out of the screensaver to let it run again.
then, I got a few lines from the log and noticed the viewer stopped... Feb 15 22:15:19 squeezeplay: INFO applet.ImageViewer - ImageViewerApplet.lua:70 init image viewer Feb 15 22:15:19 squeezeplay: INFO applet.ScreenSavers - ScreenSaversApplet.lua:259 activating ImageViewer screensaver Feb 15 22:20:10 squeezeplay: WARN squeezeplay.timer - Timer.lua:193 timer error: ...share/jive/applets/ImageViewer/ImageSourceServer.lua:209: attempt to concatenate local 'line' (a userdata value) Feb 15 22:20:35 squeezeplay: WARN applet.ScreenSavers - ScreenSaversApplet.lua:222 A screensaver is already active - ignoring activate request. Feb 15 22:21:04 squeezeplay: WARN net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {Main Server_Request}(R)) A problem with overlapping the SS seems to be a possibility.
Could you please check the SS timeout and the imageviewer change interval? I only seem to be getting those messages if both are set to 30 seconds...
30 sec SS delay, 5 Second image delay, Facebook photos as the SS.
stopped again, log showing the same message. So, must have something to do with multiple triggers.
Created attachment 6528 [details] text version of Kevin's log
== Auto-comment from SVN commit #8505 to the repo by mherger == == https://svn.slimdevices.com/?view=revision&revision=8505 == Bug: 14326 Description: if download of an image failed, imgReady was never set to true again. Thus no new image would be requested. Set imgReady = true and self.image = nil instead. This will cause an error message to be displayed, but the timer to be reset to download the next image.
== Auto-comment from SVN commit #8506 to the repo by mherger == == https://svn.slimdevices.com/?view=revision&revision=8506 == Bug: 14326 Description: increase log level on some failure situations to gather more information
Hmm... My change didn't fix this. This morning the screensaver was stuck again. And I did get the WLAN message too: Feb 18 23:56:13 squeezeplay: audio_thread_execute:798 xrun (snd_pcm_wait) Feb 18 23:56:13 squeezeplay: audio_thread_execute:752 underrun!!! (at least -816647987.898 ms long) Feb 18 23:56:13 kernel: NETDEV WATCHDOG: wlan0: transmit timed out Feb 18 23:56:13 kernel: ------------[ cut here ]------------ Feb 18 23:56:13 kernel: WARNING: at net/sched/sch_generic.c:226 dev_watchdog+0xc0/0x148() Feb 18 23:56:13 kernel: Modules linked in: sd8686 Feb 18 23:56:13 kernel: [<c02fb2b4>] (dump_stack+0x0/0x14) from [<c004e710>] (warn_on_slowpath+0x4c/0x68) Feb 18 23:56:13 kernel: [<c004e6c4>] (warn_on_slowpath+0x0/0x68) from [<c0290b0c>] (dev_watchdog+0xc0/0x148) Feb 18 23:56:13 kernel: r6:c736d1c4 r5:c0427bcc r4:c736d000 Feb 18 23:56:13 kernel: [<c0290a4c>] (dev_watchdog+0x0/0x148) from [<c0058bd4>] (run_timer_softirq+0x254/0x2fc) Feb 18 23:56:13 kernel: r7:c0290a4c r6:c7c2e000 r5:c04107c0 r4:00000000 Feb 18 23:56:13 kernel: [<c0058980>] (run_timer_softirq+0x0/0x2fc) from [<c0053ffc>] (ksoftirqd+0x1d0/0x2e8) Feb 18 23:56:13 kernel: [<c0053e2c>] (ksoftirqd+0x0/0x2e8) from [<c0064024>] (kthread+0x54/0x80) Feb 18 23:56:13 kernel: [<c0063fd0>] (kthread+0x0/0x80) from [<c0052270>] (do_exit+0x0/0x670) Feb 18 23:56:13 kernel: r5:00000000 r4:00000000 Feb 18 23:56:13 kernel: ---[ end trace a4ac4a126de732bb ]--- As I was looking at my home server's log file I saw that Touch requested a new IP address this morning when I woke it up from the stuck screensaver. I wonder whether it had lost any network connectivity between the above message and my waking it up this morning. Felix - should the device recover from whatever is causing the above message? Is there some power saving in the wlan module which might make the connection go away and not re-establish unless the user is actively using the player? The disconnect happened pretty much exactly 4h after the screensaver had kicked in (which means after I've been using it for the last time)
When I asked Richard about this particular wlan driver error message a while back he said that they are harmless. I've seen them myself and Fab4 functioned normally after that. Fab4 and Baby wlan are not using any power save modes. Only Jive does. Controller part (Comet) maintains an active TCP connection at all times and so does the player part (SlimProto) provided that the server Fab4 is connected to is available. If there is an network interruption or the server goes away temporarily both retry hard to reconnect. You can check the persistent connections with netstat -an
== Auto-comment from SVN commit #8526 to the repo by mherger == == https://svn.slimdevices.com/?view=revision&revision=8526 == Bug: 14326 Description: improve behaviour when screensaver fails to load image. Give feedback to the user and try again - but no more than 50x.
== Auto-comment from SVN commit #8560 to the repo by mherger == == https://svn.slimdevices.com/?view=revision&revision=8560 == Bug: 14326 Description: more reliability improvements to ImageViewer - not only retry to download the image, but the image list too - if the imagelist is empty, don't cancel, but try again later Kevin - please give this a try. It's the first time the facebook screensaver survived a full night. Either this fixes the issue, or it was the first time without network hiccup :-)
Created attachment 6564 [details] log when the failure happened yes, it's not fixed yet, but first time I've seen it happen in real time and was able to get the logs
== Auto-comment from SVN commit #8574 to the repo by mherger == == https://svn.slimdevices.com/?view=revision&revision=8574 == Fixed Bug: 14326 Description: ImageViewer screensavers relying on a remote server would get stuck if the server it's connected to went away for whatever reason. IV wouldn't recover once the server was back. - show message about the failed update of the picture list - make sure the update is tried again, not only when we're displaying the last element of that list, but when we've failed before - make sure the "Loading..." screen is hidden when the download fails during the initialization I really hope this is fixed now...
Argh... still crashes at some point: Feb 26 23:00:08 squeezeplay: DEBUG applet.ImageViewer - ImageSourceServer.lua:251 image ready Feb 26 23:00:08 squeezeplay: DEBUG applet.ImageViewer - ImageViewerApplet.lua:550 image rendering Feb 26 23:00:08 squeezeplay: ERROR squeezeplay.ui - jive_surface_get_size:548 Underlying sdl surface already freed, possibly with release() Feb 26 23:00:08 squeezeplay: ERROR squeezeplay.task - Task.lua:75 task error renderImage: ...share/jive/applets/ImageViewer/ImageSourceServer.lua:297: attempt to index a nil value Feb 26 23:00:08 squeezeplay: stack traceback: Feb 26 23:00:08 squeezeplay: /usr/share/jive/jive/ui/Task.lua:75: in function 'resume'Feb 26 23:00:08 squeezeplay: /usr/share/jive/jive/ui/Framework.lua:317: in function 'eventLoop' Feb 26 23:00:08 squeezeplay: /usr/share/jive/jive/JiveMain.lua:422: in function </usr/share/jive/jive/JiveMain.lua:264>Feb 26 23:00:08 squeezeplay: (tail call): ? Feb 26 23:00:08 squeezeplay: /usr/share/jive/jive/JiveMain.lua:637: in main chunk Feb 26 23:00:08 squeezeplay: [C 0x53ec5]: ? Feb 26 23:00:08 squeezeplay: [C 0x292f9]: ? Feb 26 23:01:05 squeezeplay: WARN net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {mysqueezebox.com_Request}(R))
== Auto-comment from SVN commit #8599 to the jive repo by mherger == == https://svn.slimdevices.com/jive?view=revision&revision=8599 == Fixed Bug: 14326 Description: fix typo
== Auto-comment from SVN commit #8618 to the jive repo by mherger == == https://svn.slimdevices.com/jive?view=revision&revision=8618 == Bug: 14326 Description: - add specific error when server doesn't return a valid image list - fix crasher in error message display... - hide error message to continue slide show if possible
This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release. If you are still seeing this issue, please let us know!