Thanks, I'll look at this for 7.3.

Created attachment 4305 [details]
SBC log

More data:

As an experiment i tried the following a restart of SC from the shell on my server.
So I restarted service squeezecenter and the SBC recovered playback without problems ?

So i did a stop command and then waited a long time  and then i issued the start command and behold and the SBC could recover from that to ?
(had to fiddle a little back and forth but is tarted again.

Now i powered down my server and quickly restarted again and this also ok ?

Now a longer powered of state, then the bug returned !
we must wait a while after power down for this to happen.
And it is a difference between stopping SC and power of the server.

I attach log from controller

Please hint me on what logs to activate in SC

I also attach server

Version: 7.3 - 23952 @ Tue Nov 18 03:45:12 PST 2008
Hostname: hal.home.lan
Server IP Address: 192.168.1.5
Server HTTP Port Number: 9000
Operating system: Red Hat - EN - utf8
Platform Architecture: i686-linux
Perl Version: 5.8.5 - i386-linux-thread-multi
MySQL Version: 4.1.20

Created attachment 4306 [details]
server log from SC

Thanks for the information Mikael, I am still investigating this.

Fixed squeezeplay to reconnect to the server if the server ip address changes in r3412. This is a potential cause of this problem.

Fixed an additional problem in r3413 when the Controller wakes up from suspend.

Mikael, can I ask you retest with this tomorrow (when the next nightly is available). If you still see the problem then please reopen this bug. Thanks.

Hi tested with 3427 still crashes, It appears to work your back on your controller player screen you press play nothing happens ? then you select another player just to see if everything else is ok (it is ) when you are going to select the "controller player" again then you get endless spinning circle.

When I did the required restart, I had to remove the headphones once to get i to work again, so it's actually worse.

I'm playing a local file while trying this.

Another observation if you go to select music source for controller  I see that squezenetwork is missing only local server is available.

My networks is fixed ip's only no DHCP server, so all my stuff has the same ip all the time.

I'll attach more controller log files.

the log dir on my SD card was empty ? no logs sorry.
Is that another bug ?

audio playback is beta in 7.3, moving to 7.3.1 so as not to block 7.3

Further testing shows that, if use the "controller player" stops it, shifts to some of my other players then turn of my server and restarts it.
Then the option to choose controller under choose player menu is gone ?
(It comes back when i restart the SBC as usual).
Furthermore plugging in the headphones does nothing at this stage.

But if I deselect and then select "Audio playback" again.
the controller player returns to the "choose player" menu, and is working again.

So there is a workaround, so you don't have to reboot the controller.

Before turning of the server stop playback select any other player, and when your server is up and running again toggle the "audio playback" option off and on again.

This is not a practical workaround but maybe it gives you a clue on what goes on.

Richard, I had to revert r3412, mentioned in comment#6, to fix Bug 10120

Changing target to next release

another test when SBC is in such a state that there is no controller player to choose, it does not pop up when you plug in your phones either.

reebot of sbc fix this.

seems like SC must be up first, then everything works.

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

*** Bug 10321 has been marked as a duplicate of this bug. ***

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

There is a work around that the community has come up with in the above forum post.

Richard: can you investigate this?

For the first time since I purchased my SB Duet, this is working properly on my controller with 7.3r3993 and SC 7.3.3 - 24903 under Windows.  Enabled audio playback, rebooted controller.. Plugging in headphones switched the audio over to the headphones and killed the controller's speaker.. I did then have to manually select the Controller as the player though.  Seems like most of my music sources with the exception of Rhapsody and Slacker work through the controller.

OK, well -- scratch my last comment.. It is no longer working -- but at least I know it has worked once and it appears to be a software issue, not a hardware issue.. Plugging headphones in now doesn't switch anything at all, and sound continues to come from Controller's speaker.

Richard: take a look at this forum thread, they have a solution:

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

Rick: Did the solution at the above forum thread help you resolve the issue?

I wouldn't quite call that a solution.

Basically, you are modifying the code to stop any headphone detection and to always assume the headphones are plugged in.  A proper solution would allow for the operation of the external speaker as well.

From some perusal of the code, there appears to be some way for us to determine the hardware state of the headphone jack using the "jivectl" app on the controller.  I could be misunderstanding the purpose of that app though.  The ioctl for the headphone appears to be 18.

My understanding would be that "jivectl 18" should report to us how the jiveBSP.ioctl(18) call should return.  This return should be 0 or 1 and is used as the "inserted" value used to determine what output should be used.

Of course, if 18 isn't the proper value for headphone insertion or there is a bug in the hardware interface, there will be some errors.

I could be way off, but this seems to be the way things work looking at the lua code.

(In reply to comment #20)
> I wouldn't quite call that a solution.

I agree. It is not a solution. I'm the guy who posted this workaround in the forum thread. I was not able to get any sound at all through my headphones, so I made this workaround to be able to use my headphones until someone fixed the bug.

> My understanding would be that "jivectl 18" should report to us how the
> jiveBSP.ioctl(18) call should return.  This return should be 0 or 1 and is used
> as the "inserted" value used to determine what output should be used.
> 
> Of course, if 18 isn't the proper value for headphone insertion or there is a
> bug in the hardware interface, there will be some errors.
>
> I could be way off, but this seems to be the way things work looking at the lua
> code.

I think you are right. 18 might be the wrong value, but I have not been able to find a list over these values so I don't know.

I also could not get controller to automatically detect headphone insertion.  Tried rebooting controller with headphones plugged in, but sound continues to come from speaker.  Added the "inserted = 1" line into the .lua file, and now the headphone is my only way to hear sound from controller.  I have the 7993 firmware on controller, and am running 7.3.3 squeezecenter (not sure which nightly version) on Debian (ubuntu).

We are now planning to make a 7.3.3 release.  Please review your bugs (all marked open against 7.3.3) to see if they can be fixed in the next few weeks, or if they should be retargeted for 7.4 or future.

Thanks!

Latest findings re "headphone switching" here, using SC 7.4-25680 and (unreleased) Jive 7.3-4842:

1. When Controller player is available, inserting headphones will switch to the controller player and activate headphone output.

2. When removing the hp plug from the Controller, it will continue playing through its speaker, plus revert to the player selected before (?).

3. After this happens once, re-inserting the hp plug will apparently NOT switch it back to headphones.

4. Interesting: While typing this, I switched back to the controller player because the speaker sound was so ugly, and stopped playback (holding PAUSE). My headphones were still inserted from the last tries (where it insisted in playing through the speaker nevertheless). After about the time I needed to type this (5 minutes?) I hit the PAUSE button again, and NOW it plays through my headphones!

I DID try pausing/stopping before (when it wouldn’t detect the inserted headphones), without this result.

It appears that maybe the switch state isn’t checked that often, or it needs some time to recognise it again? Or maybe we miss a check where we should do one (programmatically)?

Hope this helps a little to further diagnose/fix it :-)

(In reply to comment #24)

Add

3a. Not even after manually switching back to the Controller player.

(In reply to comment #24)

Add

5. After (4) has happened once, inserting/removing headphones will ALWAYS switch correctly. I THINK this is because the "Controller" player was (manually) selected before, so it either doesn’t switch players at all or switches between "Controller" and "Controller".

6. Yep. (5) is reproducable: If the Controller was selected before, it will switch headphones correctly. (IF enough minutes have passed.)

7. When switching to or from the Controller due to a headphone jack inserted, it will also not update the "Now Playing" screen but still show what was last on the "previous" player selected.

---

I wonder why the automatic switch to the Controller Player was done in the first place. It might even confuse people if they miss the short "Connecting to Controller" message, believe they are still connected to the last player selected, and try to control it. This automatism also seems to introduce some more bugs.

Couldn’t we just scrap all the automatic player-switching and rely on the user to select which player (s)he actually wants selected?

A new behavior I Now you can sometimes choose the SBC player without rebooting.
with the latest fw's and SC's

But i managed to do another thing I turned of Suspend and WPS to try another thing

and inserted the headphones, then the controller rebooted , note that the controller was on before i turned on Squeezecenter this morning

*** Bug 11537 has been marked as a duplicate of this bug. ***

Since there's now a planned 7.3.3 release, bugs which won't make the cut-off are being moved to the next target out.  If you feel that this bug needs to be addressed more (or less) urgently than the 7.4 release, please cc chris@slimdevices.com and leave a comment in the bug to that effect so we can review it.

Thanks.

I'm still finding the headphone switching totally unpredictable with r5225. It worked once.  r 3993 was far more reliable.  A shame because I really like the facility.

Not a final solution but perhaps the following could be implemented as the latest beta method,

IF Audio Playback is enabled AND the Controller is selected as a player AND is selected ON, assume listening through headphones is required and switch the jack on/speaker off.

Keith

This bug seems to be two... there is the issue reported below about that the controller needs to be rebooted to get the internal speaker working again for playback... but it also refers to the bug that the controller doesnt sense when headphones are plugged in... at the moment there is a workaround posted on the forum which means you can set it so that it always pushes sound throught headphones, when controller playback is selected.

Is that right.

Even though this workaround has been posted... it doesnt seem to be addressing the real issue.

The workaround is here

http://forums.slimdevices.com/showthread.php?p=422628#post422628

Created attachment 5223 [details]
modified applet to log headphone routines

-added some logging nearby headphone routines
-added timer to periodically log ioctl(18)
-to be easily accessible, all my modifications are surrounded by "-- @GEORGIANO" comments
-all my logs are grep-able with "GEORGIANO" string

Created attachment 5224 [details]
/var/log/messages generated with modified applet

here are some more facts about this problem with my controller
PID: LZ822S2
MAC: 00:04:20:1A:6A:8A
P/N: 830-000019
M/N: C-RL65
IC ID: 1807A-CRL65
FW: r3993


what I did:
1. modified SqueezeboxJiveApplet.lua:
	added some logging nearby headphone routines
	added timer to periodically log ioctl(18)
	to be easily accessible, all my modifications are surrounded by "-- @GEORGIANO" comments
	all my logs are grep-able with "GEORGIANO" string
2. uploaded modified applet to controller with scp
3. Audio playback is enabled on controller, sound heard only in speaker
4. powered controller off
5. run scenario below
6. downloaded /var/log/messages from controller with scp

scenario:
-------------------------------------------------------------------------
-powered on with headphones plugged - no sound in headphones, plugging/unplugging doesnot help.

-headphones plugged, song paused - screen got black after clock, quite time passed
 "daemon.notice wpa_supplicant[288]: WPA: Group rekeying completed with 00:1c:f0:df:50:0d [GTK=TKIP]" GOT IN LOG
-powered on, resumed - sound in headphones. 
-pause/resume - sound in headphones.
-unplugged - sound in speaker, repluging doesnot help, sound in speakers.

-headphones plugged, song paused - screen got black after clock, quite time passed
 "daemon.notice wpa_supplicant[288]: WPA: Group rekeying completed with 00:1c:f0:df:50:0d [GTK=TKIP]" GOT IN LOG
-powered on, resumed - sound in headphones.
-pause/resume/next/prev - sound in headphones.
-unplugged - sound in speaker, repluging doesnot help, sound in speakers.

NOW THE MORE INTERESTING PART

-headphones plugged, song paused - screen got black after clock
 "daemon.notice wpa_supplicant[288]: WPA: Group rekeying completed with 00:1c:f0:df:50:0d [GTK=TKIP]" NOT YET IN LOG!!!
-powered on, resumed - sound in SPEAKERS ONLY, nothing helps

-headphones plugged, song paused - screen got black after clock, quite time passed, 
 "daemon.notice wpa_supplicant[288]: WPA: Group rekeying completed with 00:1c:f0:df:50:0d [GTK=TKIP]" GOT IN LOG
-powered on, resumed - sound in headphones.
-------------------------------------------------------------------------


controller was never turned off by power button during this scenario

take notice on "daemon.notice wpa_supplicant[288]: WPA: Group rekeying completed with 00:1c:f0:df:50:0d [GTK=TKIP]"
does it have to do something with the solution? 
when in sleep mode and this message logged, sound was heard in headphones when recovered from sleep

ioctl(18) most time gives false report about headphones
switch event only gets called when headphone works and after that gets unplugged. reverse never triggered
take a look at log file grep-ed with "GEORGIANO"

actually there is veeery low volume sound in headphones when I write sound in speakers only

*** Bug 12151 has been marked as a duplicate of this bug. ***

georgiano, can you try your patch/experiments using the 7.4 Jive firmware.  This is scheduled to be fixed using that branch of the firmware.

Reset priority before triage.

*** Bug 10657 has been marked as a duplicate of this bug. ***

Steven, could you see if this is reproducible with the current 7.4 build?

Adding time data

I just upgraded to r7084 firmware (SqueezeCenter 7.4 - r28194).
The issue is still present :(

I tried with 2 different cheap noname headphones, as well as a Beyerdynamic DT 770. 
- Headphone plugged off, I start playing music, it comes from controllers built in speaker
- I plugin headphone - no changes - music from speaker but not from headphone.

Same when headphones are connected while powering up.
Same after factory reset. 

When using the 'fix' from the forum on 6038-firmware I get proper sound from the headphones. 
If there is any information I can give, I'll to help pin down the problem.
I really like to see the switching to be done automatically.

I'm running 7.3 r6038 on my controller and can confirm that the bug still persist now nearly a year later.

Can we help you with more info to eventually get this bug fixed?

/Fedder

This appears to be working properly for me with controller 7.4.0 r7084 and Squeezebox Server 7.4 r28194 running on x86 Mac with 10.5.

Stefan Hansel, what operating system are you running Squeezebox Server on?

This is working for me on Controller 7.4.0 r7084 with test.squeezenetwork.com as well.

(In reply to comment #42)
> Stefan Hansel, what operating system are you running Squeezebox Server on?

I'm currently able to run the following:
FW7084 + Server r28192 on WinXP
FW6038 + Server 7.3.3 on linux (Linkstation NAS).

I try to play a 'local' album, I'm not connected to squeezenetwork (though I created an account on test.squeezenetwork.com for the 7.4FW)

Why is the operating system important, I thought the headphone was completely controlled on the controller ? Any debugging I can turn on to help you ?

Same to me - sound to be heard on the controller but no sound on headphones.

FW r7115 - Win XP SP 3 - last recent nightly

I dived a bit into sourcecode (jivemgmt.c + jivectl.c of FW6083).
If I understand it correctly a call to 

jivectl 18

talks to the driver /dev/misc/jivemgmt via ioctl which in turn returns headphone status:

---
case JIVE_MGMT_IOCGPHONEDETECT: 
  s3c2410_gpio_cfgpin(S3C2410_GPG14, S3C2410_GPG14_INP);
  val = (s3c2410_gpio_getpin(S3C2410_GPG14) > 0);
  s3c2410_gpio_cfgpin(S3C2410_GPG14, S3C2410_GPG14_EINT22); 
---

If I ssh to the controller and call 'jivectl 18' I constantly get returned a 0 even if the headphones are inserted.

Just as I was testing (FW6083), only once I constantly got the right results from the call to jivectl. (controller then was connected to my SqueezeBox), when I switched the player back to 'Controller' this was gone. Restarting or whatever I try (switching players, switching to Squeezenetwork, removing battery) doesn't help - now again a constantly get a 0 as return value.

Some more information (this time FW7172, latest nightly).

I got headphones working shortly today again. I think the controller went into standby after some time I was not using it (it wasnt put into the cradle). After turning it on I saw a short 'please wait' message. 
Then the headphone switching was working (testet it just with the 'clicking'-sound when scrolling through menus), the controller didn't seem to be connected to any player (no check in the menu 'select player'). 

On ssh-shell I did a  
evtest /dev/input/event0

when removing the headphones there were 2 lines: one for the removal and one '-- report sync ---'.
After that no events were reported anymore and headphone switching didn't work again :(

I really need some feedback from you now! What further steps and tests can I do to support you in tracking or reproducing the problem ?

Can we get read access on bug 13526 that this bug now depends on or is it read-protected by purpose ?
If so I'd really be interested in a short summary of the current state at least.

*** Bug 13419 has been marked as a duplicate of this bug. ***

Reseting priority.
Moving out to 8.0
Reassigning to Richard.

While I'm personally a fan of this feature, it's not a priority for our next release. Please note that the functionality will still be available as an unsupported "beta" feature, just as it has been in the past.

In other words, enjoy it, but your mileage may vary.

(In reply to comment #50)
> Moving out to 8.0

Could you please clarify what the current schedules for 7.4 & 8.0 are ?

This is a main feature not working at all for many people as this bug report and all its duplicates show. 'enjoy it' are not exactly the right words for this situation.

This feature is advertised by a lot of reviews out there, so customers are expecting it to be working.

This is one of your top-10 voted bugs, so it would be really nice to get more information, than just having it put to a version with an unknown release-date.

As I really was enthusiastic in helping out to narrow down the problem the current state is really dissatisfying.

(In reply to comment #51)
You can view our Software Road map from our Public Wiki

https://wiki.slimdevices.com/index.php/SoftwareRoadmap

(In reply to comment #50)
> Reseting priority.
> Moving out to 8.0
> Reassigning to Richard.
> 
> While I'm personally a fan of this feature, it's not a priority for our next
> release. Please note that the functionality will still be available as an
> unsupported "beta" feature, just as it has been in the past.
> 
> In other words, enjoy it, but your mileage may vary.

Hi Seth,

So you're slashing it to the next release scheduled for sometime in 2010... 

When I bought my Duet I was well aware of the headphone jack and that it was equipped with a pretty decent DAC, so a great part of my initial desire for buying into the Duet was to listen to music from the Controller, while moving around the house. Now I just learned that this feature is not slated to work reliably before at least two years after the product was launched.

It seems like you're adopting Ballmer business logic here. Rather than concentrate on eliminating bugs in the current product line, you push new products out of the door and tell people to upgrade. I wish you great luck on that endeavor, but have no plans on following your path.

Let me draw up an analogy here. You go and buy a new estate car. When you come home and want to load some luggage in the trunk, you find that most of the time the handle doesn't work and you have to go through some lengthy procedure to open it. Obviously upset you go back to the dealer to have it fixed, and much to your surprise he tells you to come back some time next year, because that feature is marked as a beta.

So come on, show some pride in your product line and fix those errors. -Or is it because you have created a device so complex that you simply cannot get it to work reliably?

Happy hacking,
/Fedder

I bought multiple controllers (6!) and am feeling pretty let-down by this.  From the hardware beta and on, we were led to believe that the controller would feature audio-out and that it would be a supported feature.  I understand that you guys are trying to get new products out the door with very, very limited resources.  But this seems like a place where you've let your normally very high standards slip....a lot.

*** Bug 14689 has been marked as a duplicate of this bug. ***

*** Bug 15185 has been marked as a duplicate of this bug. ***

I voted for this to be a priority, I downloaded an applet which has at least for now fixed the problem for me.

Richard is no longer available to us.

Unassigned bugs cannot have a priority.

bug 11283

I understand that some people would really like to see some work here but it is pretty much guaranteed that it is not going to happen.

Despite the presence of a headphone jack, and some discussion during the beta period of having audio available that way, it turns out that this has a heap of problems and these are simply not going to be fixed. It is one of those (rare) beta features that never made it to product release.

That's kind of rubbing salt into the wounds of those of use who bought multiple controllers.

I am quite happy with the beta feature as it is, and I can't believe that detecting a headphone being plugged in should be such a difficult thing.