[Gigantur]

Same as above

Play for 5 minutes roughly
Pause
Standby TV for 2 minutes roughly
Wake TV
Play
(Problem evident)

debug

[Memphiz]

Nope - this time we got over that reset callback - the issue is another now. This time we didn't get the notification about changed audio devices - trying to access the old outdated deviceid of your hdmi device.

@FernetMenta - is it save to call CAEFactory:eviceChange(); from withing CAESinkDARWINOSX::Initialize?

[FernetMenta]

Yes AE tries again and again but can't open audio.

[Memphiz]

@Gigantur 2 new testbuilds:

http://mirrors.xbmc.org/test-builds/osx/...x86_64.dmg

http://mirrors.xbmc.org/test-builds/osx/...x86_64.dmg

The first one would be my favorite solution if it works.

[repstein]

I'll be able to test shortly.

[repstein]

First one: No crash, otherwise, same issue still.

Debug log

Trying the second one now ..

[repstein]

Second build: So, the first time I tried to recreate it, it didn't work as usual.

I then did the usual: exited, cleared the logs, loaded back up, turned debug on, played a movie, paused it, shut off TV, turned TV back on, unpaused movie, and it worked fine. Paused it again, turned off TV, turned on TV, unpaused, and no audio/slow frame rate. Stopped movie, turned off debugging, uploaded debug log.

Debug log

---

I guess the good news is you fixed the crashing issue that started a few builds ago.

[Memphiz]

@FernetMenta please have a look at http://xbmclogs.com/show.php?id=151313

The other log indicates that we are in a state where we are not able to open the hdmi device at all (though that device id is reported as default device). I start to get out of ideas to be honest

[repstein]

I bet I can solve this issue for $129 per TV:

http://www.gefen.com/kvm/ext-hdmi-edidp....od_id=8005

---

http://www.amazon.com/Gefen-EXT-HDMI-EDI...B001RIMZUW

Reviews are interesting.

---

Looks like a bunch of XBMC users have purchased this to solve this very issue.

---

It really amazes me that no one has figured out a solution here (other than throwing hardware at it).

[Memphiz]

Now you see how good the mainstream engineers are when it comes to implementing the HDMI standard. This is the result of either uncapable people - or time pressure and budget shortcuts. And yes of course it sucks ass.

[FernetMenta]

@FernetMenta please have a look at http://xbmclogs.com/show.php?id=151313

The other log indicates that we are in a state where we are not able to open the hdmi device at all (though that device id is reported as default device). I start to get out of ideas to be honest

This log indicates the the thread is blocked in OpenSink for too long (15 sec):
11:30:30 T:4477104128 DEBUG: CActiveAESink::OpenSink - trying to open device DARWINOSX:default

can we disable the device change events for a test on those systems? (same build as this log was done)

[Memphiz]

Good that darwin builds only last 10 minutes on jenkins

@repstein would you be so kind again please? (disabled devicechange callback)

http://mirrors.xbmc.org/test-builds/osx/...x86_64.dmg

[repstein]

This build fixed the problem it seems. I'll generate a debug shortly.

[Gigantur]

@Gigantur 2 new testbuilds:

http://mirrors.xbmc.org/test-builds/osx/...x86_64.dmg

http://mirrors.xbmc.org/test-builds/osx/...x86_64.dmg

The first one would be my favorite solution if it works.

OK. On it now. Back shortly with results ..

[Gigantur]

@Gigantur 2 new testbuilds:

http://mirrors.xbmc.org/test-builds/osx/...x86_64.dmg

http://mirrors.xbmc.org/test-builds/osx/...x86_64.dmg

The first one would be my favorite solution if it works.

OK. On it now. Back shortly with results ..

First build - looks very good

Test 1 - Result: Did not replicate problem - all good although (I did notice 1 or 2 secs of issue then it recovers
Test 2 - Result: Did not replicate problem - all good

Second build

Test 1 - Result: No Audio and Jerky video - Debug


I probably need more time for testing on "First build" to be confident as the results of a previous build looked very good initially as per this post ..

I also had a thought - might the results be dependent on "audio keep alive" (1 minute in my settings at present) - I think my TV does a "firmware search" for the first part of standby then it makes a clicking sound and is fully in Standby (I have been waiting for this "real standby" before waking then testing).

For example, perhaps the keepalive keeps sending a silent audio stream and there is a race condition with standby - I will time the TV from clicking standby to the click.

It is worth noting that rebooting the mac with the TV fully off leads to graphics device initialisation errors (yet rebooting with TV in standby is fine - this suggests the two are different states). At one stage I wanted to reboot each night (due to EyeTV issue) - I had to write a bit of shell to check the TV was detected in system profiler (i.e in standby) and reboot only if so.


UPDATE:

Third Build - Latest in the thread - Also looks very good

Test 1: All good (I did notice 1 or 2 secs of issue then it recovers)
Test 2: All Good


In terms of the instances of 1 or 2 secs of issue and then recovery from it - this build was fine the whole time of the tests (albeit with other issues)