Bug 13993 - SqueezeCenter backup alarm does not loop on SP devices
: SqueezeCenter backup alarm does not loop on SP devices
Status: CLOSED FIXED
Product: SqueezePlay
Classification: Unclassified
Component: SB Server
: unspecified
: PC Other
: P1 normal (vote)
: 7.4.0
Assigned To: Richard Titmuss
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-11 16:02 UTC by Ben Klaas
Modified: 2009-10-05 14:32 UTC (History)
4 users (show)

See Also:
Category: Bug


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ben Klaas 2009-09-11 16:02:53 UTC
not to be confused with the RTC fallback alarm on Baby, the backup alarm from SC, used when the configured SC alarm playlist can't be played, only sounds its tone once and does not repeat.

Felix, do you know if Boom uses this tone and if so, does it force repeat mode to enable the looping?
Comment 1 Chris Owens 2009-09-15 17:29:09 UTC
Ben I got a note from Pat that you need QA's help with this.  Do you want us to confirm this behavior?
Comment 2 Ben Klaas 2009-09-15 18:10:39 UTC
I'm having have trouble but I certainly didn't ask for QA's help with this.
Comment 3 Ben Klaas 2009-09-17 22:10:25 UTC
Alrighty, now I am asking for help :)

From SC Web UI I tune directly to
loop://<ip address>:9000/html/slim-backup-alarm.mp3

It only plays once and stops. Any idea why it doesn't loop?
Comment 4 Chris Owens 2009-09-21 09:49:39 UTC
Andy suggests trying the 'coins' natural sound to see if that plays.  

Andy says he'll look at it to see if it's a firmware or SC bug.

Pat notes that if it's a problem with too short a sound, and fafafa works, that we should just put that in to the server.
Comment 5 Andy Grundman 2009-09-21 12:21:10 UTC
This appears to be an SP bug:

Sep 21 15:20:06 squeezeplay: INFO   audio.decode - decode_start_handler:274 
init decoder mp3
Sep 21 15:20:06 squeezeplay: INFO   audio.decode - Playback.lua:384 connect 
192.168.100.12:9000 GET /html/slim-backup-alarm.mp3 HTTP/1.0^M
Sep 21 15:20:07 squeezeplay: playback_callback:338 Audio underrun: used 128 
frames , requested 441 frames
Sep 21 15:20:07 squeezeplay: playback_callback:328 Audio underrun: used 0 bytes
Sep 21 15:20:07 squeezeplay: playback_callback:328 Audio underrun: used 0 bytes
Sep 21 15:20:07 squeezeplay: playback_callback:328 Audio underrun: used 0 bytes
Sep 21 15:20:07 squeezeplay: playback_callback:328 Audio underrun: used 0 bytes
Comment 6 SVN Bot 2009-09-22 03:11:57 UTC
 == Auto-comment from SVN commit #7681 to the jive repo by richard ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7681 ==

Bug #13993
Fixed looping tracks in SP. This problem did not always happen, but appears to be more of a problem on slower 
devices.

The streambuf loop pointer was often being set incorrectly, due to a difference in the network stacks on SP 
and ip3k. To fix this the loop pointer is now always set after the http headers. If looping is then required 
the loop flag is flipped to turn it on.

This removes the streambuf_*_loop public interface. The semantics have changed, and this interface was not 
actually used.

Tested with the backup alarm as described in the bug.
Comment 7 Richard Titmuss 2009-09-22 03:32:33 UTC
Now tested with baby firmware, it's fixed.
Comment 8 James Richardson 2009-10-05 14:32:55 UTC
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server!
    * SqueezeCenter: 28672
    * Squeezebox 2 and 3: 130
    * Transporter: 80
    * Receiver: 65
    * Boom: 50
    * Controller: 7790
    * Radio: 7790  

Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes

If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.