PDA

View Full Version : 7.4.2 nearing release, need your help!



ChrisOwens
2010-01-28, 16:43
We're trying to release 7.4.2 shortly to fix two primary issues and a small number of lesser issues with Squeezebox Radio.

1) Alarm reliability
2) Network reliability

The current 7.4.2 build is release-candidate quality (so it should be pretty safe to run, without major bugs). If you have some time to please check out the current 7.4.2 build and file some bugs, ESPECIALLY if you've been experiencing problems with network connectivity OR alarms (or both).

It's available at http://downloads.slimdevices.com/nightly/?ver=7.4

Thanks!

benifex
2010-01-28, 23:24
I've been having some major connectivity problems--lots of dropouts. I'll give this a try and post about how I go.

WB3FFV
2010-01-29, 00:51
I'll load it up and give it a try..

Sike
2010-01-29, 01:18
I have 2 Squeezebox Radios at my parents house. They need the presets to work, as they don't/can't fiddle with the stations every time they want to listen to a radio station.

Are the presets fixed too?

ModelCitizen
2010-01-29, 01:36
I'm on 7.5 and the Radio display for he Sleep function is badly crocked for me. As far as I can see the code is the same for 7.4.2 (it has not been changed since then). I've not filed a bug as I'd prefer others to verify it first... you might be able to reproduce it easily enough at Q&A though:

Read exact description here:
http://forums.slimdevices.com/showpost.php?p=511447&postcount=8

MC

usch
2010-01-29, 23:45
I don't have a Radio, but since this is a synchronization issue the Radio might be affected, too, when it is in a sync group:

My MP3 collection consists of files of all possible sample rates. Mainly 44.1 kHz, but also 32 kHz, 48 kHz, and even the odd 22.05 kHz. My normal playback setup is a sync group of 2×SB1 and 1×Boom.

As long as I am streaming to a single player, everything is fine. But when synchronization is in effect, I experience all kinds of playback problems whenever a file is encountered that is not 44.1 kHz, such as:

- Both SB1s keep playing, but the Boom is mute while the play time on the display still counts up.
- Playback stalls altogether (stills says "Now Playing", but is stuck at 0:00 on all players).
- Title display on the players and in the web interface immediately skips to the next track in the playlist and stays one track ahead of the audio that is actually being played until I stop and restart playback.

Let me know if this is a known issue, or if I should file a bug.




[10-01-30 08:55:48.1512] Slim::Utils::Misc::msg (1165) Warning: [08:55:48.1509] Backtrace:

frame 0: Slim::Utils::Misc::assert (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Player/Squeezebox1.pm line 86)
frame 1: Slim::Player::Squeezebox1::play (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Player/StreamingController.pm line 1220)
frame 2: Slim::Player::StreamingController::_Stream (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Player/StreamingController.pm line 1264)
frame 3: Slim::Player::StreamingController::_PlayIfReady (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Player/StreamingController.pm line 288)
frame 4: Slim::Player::StreamingController::_eventAction (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Player/StreamingController.pm line 2028)
frame 5: Slim::Player::StreamingController::playerStopped (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Player/Squeezebox2.pm line 130)
frame 6: Slim::Player::Squeezebox2::statHandler (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Networking/Slimproto.pm line 871)
frame 7: Slim::Networking::Slimproto::_stat_handler (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Networking/Slimproto.pm line 408)
frame 8: Slim::Networking::Slimproto::client_readable (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Networking/IO/Select.pm line 139)
frame 9: (eval) (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Networking/IO/Select.pm line 123)
frame 10: Slim::Networking::IO::Select::__ANON__ (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Networking/IO/Select.pm line 183)
frame 11: (eval) (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Networking/IO/Select.pm line 183)
frame 12: Slim::Networking::IO::Select::loop (slimserver.pl line 620)
frame 13: main::idle (slimserver.pl line 56)
frame 14: PerlSvc::Startup (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>PerlSvc.pm line 95)
frame 15: PerlSvc::_startup (slimserver.pl line 0)
frame 16: (eval) (slimserver.pl line 0)

Here's the problem. /<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Player/Squeezebox1.pm, line 86:


[10-01-30 08:55:48.1522] Slim::Utils::Misc::msg (1165) Warning: [08:55:48.1519] Backtrace:

frame 0: Slim::Utils::Misc::assert (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Player/Squeezebox1.pm line 86)
frame 1: Slim::Player::Squeezebox1::play (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Player/StreamingController.pm line 1220)
frame 2: Slim::Player::StreamingController::_Stream (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Player/StreamingController.pm line 1264)
frame 3: Slim::Player::StreamingController::_PlayIfReady (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Player/StreamingController.pm line 288)
frame 4: Slim::Player::StreamingController::_eventAction (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Player/StreamingController.pm line 2028)
frame 5: Slim::Player::StreamingController::playerStopped (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Player/Squeezebox2.pm line 130)
frame 6: Slim::Player::Squeezebox2::statHandler (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Networking/Slimproto.pm line 871)
frame 7: Slim::Networking::Slimproto::_stat_handler (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Networking/Slimproto.pm line 408)
frame 8: Slim::Networking::Slimproto::client_readable (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Networking/IO/Select.pm line 139)
frame 9: (eval) (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Networking/IO/Select.pm line 123)
frame 10: Slim::Networking::IO::Select::__ANON__ (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Networking/IO/Select.pm line 183)
frame 11: (eval) (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Networking/IO/Select.pm line 183)
frame 12: Slim::Networking::IO::Select::loop (slimserver.pl line 620)
frame 13: main::idle (slimserver.pl line 56)
frame 14: PerlSvc::Startup (/<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>PerlSvc.pm line 95)
frame 15: PerlSvc::_startup (slimserver.pl line 0)
frame 16: (eval) (slimserver.pl line 0)

Here's the problem. /<C:\Programme\Audio\Squeezebox\server\SqueezeSvr.ex e>Slim/Player/Squeezebox1.pm, line 86:

bluegaspode
2010-01-30, 03:10
I'd love to see this alarm related bug (already flagged 'alarm_critical' by Ben) targeted to 7.4.2.
https://bugs.slimdevices.com/show_bug.cgi?id=15239

Though it seems very difficult to reproduce, there are more users (kork, wxman, jmpage2) facing this problem see following thread

http://forums.slimdevices.com/showthread.php?t=74188

Please also note that Marc already did some good investigations on it, so maybe it's not too far away to find a solution:
http://forums.slimdevices.com/showthread.php?p=511841#post511841

finnbrodersen
2010-01-31, 06:45
We're trying to release 7.4.2 shortly to fix two primary issues and a small number of lesser issues with Squeezebox Radio.

1) Alarm reliability
2) Network reliability

The current 7.4.2 build is release-candidate quality (so it should be pretty safe to run, without major bugs). If you have some time to please check out the current 7.4.2 build and file some bugs, ESPECIALLY if you've been experiencing problems with network connectivity OR alarms (or both).

It's available at http://downloads.slimdevices.com/nightly/?ver=7.4

Thanks!

I downloaded 7.4.2 r29959 for WinXP yesterday.

I have found one annoying bug so far.

the "+" menu of a song in the current playlist is not displayed correcly

e.g.

"home home center +"

The menu shows
"Add to End
"Play Next"
"Play"
"Save to Favorites"
"Remove from Playlist"
"Play Next" (again)
"Play" (again)
"Save to Favorites" (again)
"Album Artist"
...
"More Info"

The "More Info" shows "Empty" as result when selected with the Center button


I hope this bug can be fixed before 7.4.2 is released


setup
Receiver running fw 65
Controller running fw 7.4.1 r7915

Squeezebox Server Status
Version: 7.4.2 - r29959 @ Sat Jan 30 03:05:54 PST 2010
Hostname: ***
Server IP Address: ***
Server HTTP Port Number: 9001
Operating system: Windows XP - EN - cp1252
Platform Architecture: 586
Perl Version: 5.10.0 - MSWin32-x86-multi-thread
MySQL Version: 5.0.22-community-nt
Total Players Recognized: 1

Mnyb
2010-01-31, 06:57
Yep it is known, at least to Ben:

http://forums.slimdevices.com/showthread.php?t=74639

albright
2010-01-31, 07:28
"SBRto be stuffed in a box in the attic )"

I'll save you some space in your attic and pay
for shipping to Canada :)

Mnyb
2010-01-31, 07:40
"SBRto be stuffed in a box in the attic )"

I'll save you some space in your attic and pay
for shipping to Canada :)

It will be my spare when the SB3 gives up the ghost, the VFD displays have no replacement anymore. Sorry i keep it, it actually functions rather well
but...

The sbr is just so dreadful to configure.
I'm just a little miffed by the utterly ill conceived setup procedure of the duet system.
I only want to change the DNS settings in the thing, this will force a full factory reset probably of both the sbr and the controller, this will probably not work then it's time to use net::udap .
But it's still running fine on my old isp's dns hopefully it last until my Touch arrives :)

Mnyb
2010-01-31, 09:44
Oops another thing thats quite obvious, but as nobody mentioned it :

After you press + then "add to end" the next pop-up screen where it says adding to end.. I figured that the large black area in the middle probably should contain a miniature cover art, if you are very lucky you can spot it 2 times out of 100 and then only briefly before the pop-up disappears.

This is on the controller.

But I'm on 7.5 maybe some new things interfere with this ?

mule
2010-02-02, 16:00
I'm upset!
Once again the radio alarm bug: "alarm coming through headphones instead of speakers" is not going to be fixed although targeted for 7.4.x release and although it should have worked from the right beginning as Caleb has been stated on this forum!
Don't you think it's not a critical bug when you're not being waked up by an alarm because it doesn't come out of the speakers? What should be more critical than not being able to hear the alarm sound? Or are you sleeping with headphones on? :-(

mule
2010-02-02, 16:28
Great to hear that the target for the bug stated above was just moved from 7.4.x to 7.5.0. So, will it ever get fixed? Seems not! Maybe because it's hardware related and not only a software bug?! Otherwise it could not be too difficult to fix it when keeping in mind that Caleb stated that it was already working while the radio was in beta! So what is the truth about it?

bluegaspode
2010-02-02, 17:07
with 13 votes even a bug that got attention by some users :(

I don't think its a hardware bug ... my headphones switcher applet for the controller is also able to reroute the audio.
That should be possible to do in the alarm applet as well !

ChrisOwens
2010-02-02, 17:16
Right now we have users that are not able to hear their alarms AT ALL regardless of if they have headphones attached. Alarms are simply NOT GOING OFF. Can we agree that that bug is more important? I think we probably can.

The headphones bug now has a concrete target and is assigned to an actual developer who still works for the Squeezebox team. This bug is not getting fixed in a couple weeks, true, but really it's in pretty good shape!

bluegaspode
2010-02-02, 17:25
Right now we have users that are not able to hear their alarms AT ALL regardless of if they have headphones attached. Alarms are simply NOT GOING OFF. Can we agree that that bug is more important? I think we probably can.
Could you please point me to the bug-report(s) still open/worked on about not playing alarms ?
An alarm coming through headphones I consider 'not able to hear AT ALL' as well.

Mnyb
2010-02-02, 17:45
Even if the Head phone blocking speaker alarm is ridiculous and should have been caught by anything vaguely resembling of a proper testing and QA process. The fact is that it has an possible end user workaround, unplug the headphones.

The other "not able to hear alarm AT ALL" problems has no end user workarounds ? unless you bring in another device like your cell phone or old clock-radio as backup.

erland
2010-02-02, 18:04
Right now we have users that are not able to hear their alarms AT ALL regardless of if they have headphones attached. Alarms are simply NOT GOING OFF. Can we agree that that bug is more important? I think we probably can.

The headphones bug now has a concrete target and is assigned to an actual developer who still works for the Squeezebox team. This bug is not getting fixed in a couple weeks, true, but really it's in pretty good shape!

Sounds like a good trade off, we really need to get 7.4.2 out of the door so you can start selling those Radio batteries, even if this means that some people have to wait a month or two for the Touch 7.5 release until the alarm works with the headphones plugged in.

Anyone else listening, please understand that Logitech has to do priorities like this. There is no software without bugs, sometimes it's more important to release something than getting all less important bugs fixed. For the survival of the Squeezebox products it's really important that Logitech can start to sell its hardware, 7.4.2 means that they can start selling batteries, 7.5 means that they can start selling Touch devices, as a beta tester I'm sure both will be a great success.

None of my old clock radios even have a headphone socket, so as long as the Radio reliably output sound when the alarm has been scheduled, it's still a lot better than any of my old clock radios.

mbonsack
2010-02-02, 18:22
For the survival of the Squeezebox products...

This is somewhat of a thread hijack, but the comment above has me preplexed as it has been repeated largely verbatim and certainly in spirit elsewhere in the forums. If Logitech bought Slim, largely a successful niche company, why wouldn't they put the resources into the operation to ensure it thrives? Why this complete gutting of the developer base, shift to contractors, etc.? Has the market dynamic shifted that much to the point where Logitech regrets the purchase?

erland
2010-02-02, 18:34
This is somewhat of a thread hijack, but the comment above has me preplexed as it has been repeated largely verbatim and certainly in spirit elsewhere in the forums. If Logitech bought Slim, largely a successful niche company, why wouldn't they put the resources into the operation to ensure it thrives? Why this complete gutting of the developer base, shift to contractors, etc.? Has the market dynamic shifted that much to the point where Logitech regrets the purchase?

Please start a separate thread if you like to discuss this.

DaveWr
2010-02-03, 01:37
with 13 votes even a bug that got attention by some users :(

I don't think its a hardware bug ... my headphones switcher applet for the controller is also able to reroute the audio.
That should be possible to do in the alarm applet as well !

I don't think it is a bug at all. It's a WIBNI (wouldn't it be nice if...). Virtually all clock radios would work as the Radio does today. An option to be clever, is an enhancement to the product capability, not an issue with common practice as currently implemented.

Dave

bluegaspode
2010-02-03, 07:29
I don't think it is a bug at all. It's a WIBNI (wouldn't it be nice if...). Virtually all clock radios would work as the Radio does today. An option to be clever, is an enhancement to the product capability, not an issue with common practice as currently implemented.

Dave

Its a feature that already existed according to the devs (http://forums.slimdevices.com/showthread.php?t=67916) so if its not working anymore its a regression bug.
The Boom by the way also plays alarms always through the speakers, so we could also call it a 'consistency'-bug across the product line.

Anyway - I'm in the software business as well and if you just want to you can mark any bug an enhancement request (and vice versa). Its not worth the discussion.

As said its not too difficult to reroute the audio - locally I have it working already so will post a patch later on.
Hope that this work pays off - if there's not the time to fix it by logitech themselfes then hopefully the time to review and verify the patch for the 7.4.x-branch.



Sounds like a good trade off, we really need to get 7.4.2 out of the door so you can start selling those Radio batteries, even if this means that some people have to wait a month or two for the Touch 7.5 release until the alarm works with the headphones plugged in.

We waited since september for stable alarms and batteries so one or two weeks delay for a better alarm feature don't make a difference anymore, does it ?

mule
2010-02-03, 07:40
Right now we have users that are not able to hear their alarms AT ALL regardless of if they have headphones attached. Alarms are simply NOT GOING OFF. Can we agree that that bug is more important? I think we probably can.

The headphones bug now has a concrete target and is assigned to an actual developer who still works for the Squeezebox team. This bug is not getting fixed in a couple weeks, true, but really it's in pretty good shape!

Yes we can agree that no alarm is even worse in comparison to an alarm that only fires through headphones.
My only comment: Why has the radion been released with such a buggy software? Answer: Because the hardware was done long before the software was ready. Same happens now with batteries. Once again a buggy software version for the radio is beging pushed out in order to sell the batteries.
And next time there comes a buggy version for the touch, because the hardware is ready since september/october of last year?

One suggestion to logitech: Just stop the work of you hardware department and give you software department some air to breathe, because such products are only working when hardware and software fits together!

TheMule!

DaveWr
2010-02-03, 08:00
Its a feature that already existed according to the devs (http://forums.slimdevices.com/showthread.php?t=67916) so if its not working anymore its a regression bug.
The Boom by the way also plays alarms always through the speakers, so we could also call it a 'consistency'-bug across the product line.


Fair comment, if Logitech declared it to work, then it's a bug. Hope you can get a patch included.

Dave

Ikabob
2010-02-03, 08:06
I vote for getting the battery out and we can work out the remaining bugs later. I need a portable for my RR when I shower, badly. Mho. Thanks.

bluegaspode
2010-02-03, 09:33
As said I wrote a patch for the Headphones/Speaker problem, see https://bugs.slimdevices.com/show_bug.cgi?id=14742

Hope you are able to review and approve it so this can make it into 7.4.2 now and doesn't disturb the release date.

jwagner010
2010-02-05, 05:05
So when can we expect 7.4.2 to be released?