[Zgemma H7] HDMI-CEC working with Standby but not working with Deep Standby

[smipx]

Hi, I meant no disrepect due to my lack of understanding. Please don't be offended I'm trying to understand and be as helpful as possible. I appreciate you folk all do this for free in your spare time. It is not lost on me

From your description (and from the fact that normal standby works perfectly well in my setup) I too think it must be either the C++ HDMI Driver not sending the signal when choosing deep standby (or something similar) due to the H7S or it is sending it and the Soundbar is not hearing it. My setup (with the H7S plugged in to the Soundbar and the TV plugged into the soundbar) is, while not always that common, a good valid connection method and "should" work well. The Soundbar is behaving differently and possibly not right. Getting Samsung involved is going to be a waste of time so if it is not fix-able on the H7s (either by coding change or driver coding change) then I am happy to live with it as-is. I can simply perform one extra step to turn off the TV with a programmed button on my remote after I have put the H7 into deep standby. I'm not sure if ronand has his H7s plugged direct into his AMP or whether his AMP is plugged into his TV and the H7 plugged into his TV also ??

Just while I try the above latest Standby.py I wanted to double check with you. Last time I did the init 4, renamed the pyc file to pyc.old and copied the Standby.py over and the rebooted (init 6). When I look at the folder I see the pyc has reappeared. I assume that is normal and it takes your latest py file and creates the pyc from it?? Just want to be sure things are copying over properly and I am testing the right files?

 

[smipx]

The reason I asked about the py and pyc will now become apparent....

IT WORKS!

the first time I did an overwrite I renamed the pyc file and copied over the py file (hdmicec.py). On the second iteration or hdmicec.py I renamed the old hdmicec.py BUT NOT the newly auto-created pyc brother (didn't see it). I assume then that when I copied v2 py over, as there was still a pyc, it might have been using the older pyc (which by now was a version out of date)....
OR
the latest standby.py fixed it.

Whichever - I am more than happy and more than happy to do any reverse engineering to determine what "actually" fixed it at which version.

Do I now need to do any cleaning-up so that I can still use the updates from the feeds?

Thanks again twol for your perserverence. I do appreciate it )))))

 

[twol]

The reason I asked about the py and pyc will now become apparent....

IT WORKS!

the first time I did an overwrite I renamed the pyc file and copied over the py file (hdmicec.py). On the second iteration or hdmicec.py I renamed the old hdmicec.py BUT NOT the newly auto-created pyc brother (didn't see it). I assume then that when I copied v2 py over, as there was still a pyc, it might have been using the older pyc (which by now was a version out of date)....
OR
the latest standby.py fixed it.

Whichever - I am more than happy and more than happy to do any reverse engineering to determine what "actually" fixed it at which version.

Do I now need to do any cleaning-up so that I can still use the updates from the feeds?

Thanks again twol for your perserverence. I do appreciate it )))))

First I have no issues with your posts, just pleased to work with someone that has an issue, will test and provide good feedback!

So the 1st time you copy over a .py, you should rename the "official" .pyc to something else, because when you copy over the .py it will become a .pyc and also overwrite any existing .py during the copy, so you have a new .py = new .pyc.

So what I would like you to do, is backup your settings (BackupManager), then reflash the same image (ImageManager) into another slot and restore the settings - so basically you will be back to original setup.
Then try hdmicec in post #31. If that doesn't work then try the Standby in post #40.
I would like debug logs from both tests (just the debug logs where you go into deep standby)

If only the deep standby works then I will have to think about it, as the code currently, doesn't handle situations where you have recordings active or scheduled - it drops the TV/AV/sound system before checking..... > possible to handle but needs a few changes.

 

[smipx]

OK. I can do all of that. I will do it over the Easter long weekend and am away for a couple of days so there may be a bit of a delay in doing it but.... watch this space.
If I get time I will do it today

 

[smipx]

OK. Done. Results are below for part 1 and part 2 on newly reflashed image into new slot and restored settings:.

hdmicec.py (post 31) did not fix the DeepStandby issue
standby.py (post 40) DID fix the issue

Timelines:

hdmicec.py deployed
15:10 - DeepS - TV Left On/SB Left on
15:11 Return from DeepS - TV came on Soundbar came on
15:12 Regular Standby - TV and SB went off
15:12 Return from Regular Standby - TV came on Soundbar came on

hdmicec.py + standby.py deployed
15:16 - DeepS - TV and SB went off as we would like
15:17 Return from DeepS - TV came on Soundbar came on
15:18 Regular Standby - TV and SB went off
15:18 Return from Regular Standby - TV came on Soundbar came on

Logs attached:
View attachment Enigma2_debug_2022-04-14_15-09-29.log
View attachment Enigma2_debug_2022-04-14_15-10-42.log
View attachment hdmicec.log

Cheers,
Paul

 

[twol]

OK. Done. Results are below for part 1 and part 2 on newly reflashed image into new slot and restored settings:.

hdmicec.py (post 31) did not fix the DeepStandby issue
standby.py (post 40) DID fix the issue

Timelines:

hdmicec.py deployed
15:10 - DeepS - TV Left On/SB Left on
15:11 Return from DeepS - TV came on Soundbar came on
15:12 Regular Standby - TV and SB went off
15:12 Return from Regular Standby - TV came on Soundbar came on

hdmicec.py + standby.py deployed
15:16 - DeepS - TV and SB went off as we would like
15:17 Return from DeepS - TV came on Soundbar came on
15:18 Regular Standby - TV and SB went off
15:18 Return from Regular Standby - TV came on Soundbar came on

Logs attached:
View attachment 63708
View attachment 63709
View attachment 63710

Cheers,
Paul

that 2nd log only shows upto 15.15 ....> standby pressed

 

[smipx]

My bad

Here are a couple of subsequent logs that should complete the picture..
View attachment Enigma2_debug_2022-04-14_15-16-59.log
View attachment Enigma2_debug_2022-04-14_15-16-00.log

 

[twol]

OK - will have a look at cleaning up the standby code

 

[smipx]

:thumbsup:

 

[smipx]

Should I leave as-is for now or revert to the original standby.py until it is fixed. I don't want to be turning it off with a recording in progress and anything bad happening ?

 

[twol]

Should I leave as-is for now or revert to the original standby.py until it is fixed. I don't want to be turning it off with a recording in progress and anything bad happening ?

Your call - but just check whats lined up in timers

 

[smipx]

Okay - I don't use Deep standby during the day and when I do use it - it is at night and nothing scheduled to record overnight.
I use normal Standby during the day quite a bit with recordings in progress on frequent occasion. If normal Standby/recording is not affected then I'm thinking it is safe to leave as-is until the patch makes its way through the system so to speak.

Thanks twol.

Paul

 

[twol]

Okay - I don't use Deep standby during the day and when I do use it - it is at night and nothing scheduled to record overnight.
I use normal Standby during the day quite a bit with recordings in progress on frequent occasion. If normal Standby/recording is not affected then I'm thinking it is safe to leave as-is until the patch makes its way through the system so to speak.

Thanks twol.

Paul

can you try these 2 attachments!

 

[adm]

Okay - I don't use Deep standby during the day and when I do use it - it is at night and nothing scheduled to record overnight.
I use normal Standby during the day quite a bit with recordings in progress on frequent occasion. If normal Standby/recording is not affected then I'm thinking it is safe to leave as-is until the patch makes its way through the system so to speak.

Thanks twol.

Paul

Just a note: with the power timer I suggested earlier that puts the box into deep standby after the box has been in standby for 10 minutes be aware that this function is delayed if the box is busy recording. The poer timer then kicks in 10 minutes after the recoding has finished.

 

[smipx]

Results:

17:11 Goto DS - Did not work!!
17:12 Return DS - Worked
17:13 SBye - Worked
17:13 Return Sbye - Worked
17:14 Goto DS - Worked!!
17:14 Return DS - Worked
17:15 Goto DS - Worked
17:15 Return DS - Worked
17:16 Goto SB - Worked

Not sure why the 1st goto DS did not work - maybe a one off??

Logs attached:
View attachment Enigma2_debug_2022-04-15_17-15-30.log
View attachment Enigma2_debug_2022-04-15_17-14-13.log
View attachment Enigma2_debug_2022-04-15_17-12-27.log
View attachment Enigma2_debug_2022-04-15_17-10-46.log
View attachment hdmicec.log

 

[twol]

Results:

17:11 Goto DS - Did not work!!
17:12 Return DS - Worked
17:13 SBye - Worked
17:13 Return Sbye - Worked
17:14 Goto DS - Worked!!
17:14 Return DS - Worked
17:15 Goto DS - Worked
17:15 Return DS - Worked
17:16 Goto SB - Worked

Not sure why the 1st goto DS did not work - maybe a one off??

Logs attached:
View attachment 63728
View attachment 63729
View attachment 63730
View attachment 63731
View attachment 63732

The hdmicec commands were sent for deepstandby, but I can see that (I guess its the samsung soundbar) is still sending requests to the sat receiver for info, so maybe it was not ready to accept a standby command.
So I am going to examine the logs a bit more, but probably go with this code, unless you post something different over the next 2 days

 

[smipx]

I'm in your hands twol.
Whatever you think is the best solution will be fine by me.

 

[smipx]

Small update. Not sure if this is in any way linked but since upgrading to v6 (to help test this issue) I have noticed another issue that is pretty repeatable. It is to do with Timeshift.
Fairly often, when I press pause on a live TV program the box crashes.
The usage scenrio is that we press pause on a program, maybe do a bit of watching and then press stop > Don't save timeshift or Recording and then at some point a few minutes later, on the same program we may press pause again. About 3 times in 10 the box crashes - especially if one leaves it a few minutes before pressing pause again. An immediate stop TS and then pause again seems not to cause the crash. Also when doing this it will often not pause for the second time withut firstly pressing stop again (to get a red cross in the top right) and then the second pause will work.

Attached logs. Time fo crash around 08:44 and then another at around 08:47
View attachment Enigma2_debug_2022-04-16_08-46-43.log
View attachment Enigma2_debug_2022-04-16_08-41-31.log
View attachment Enigma2_crash_2022-04-16_08-41-21.log
View attachment Enigma2_crash_2022-04-16_08-46-33.log


A second scenrio that always causes a crash. I donwload the odd movie file and copy it across to the zgemma to use as a basic media player. If I copy across a file (say a film) that has a name like, say "Core Universe.DD+Atmos.m2ts" or "The.Martian.2015.mkv".

When in the Movie list if I press the IMDB button the box crashes.

Log example attached:
View attachment Enigma2_debug_2022-04-15_22-17-31.log
View attachment Enigma2_debug_2022-04-15_22-36-11.log
View attachment Enigma2_crash_2022-04-15_22-36-00.log

 

[twol]

Small update. Not sure if this is in any way linked but since upgrading to v6 (to help test this issue) I have noticed another issue that is pretty repeatable. It is to do with Timeshift.
Fairly often, when I press pause on a live TV program the box crashes.
The usage scenrio is that we press pause on a program, maybe do a bit of watching and then press stop > Don't save timeshift or Recording and then at some point a few minutes later, on the same program we may press pause again. About 3 times in 10 the box crashes - especially if one leaves it a few minutes before pressing pause again. An immediate stop TS and then pause again seems not to cause the crash. Also when doing this it will often not pause for the second time withut firstly pressing stop again (to get a red cross in the top right) and then the second pause will work.

Attached logs. Time fo crash around 08:44 and then another at around 08:47
View attachment 63734
View attachment 63735
View attachment 63736
View attachment 63744


A second scenrio that always causes a crash. I donwload the odd movie file and copy it across to the zgemma to use as a basic media player. If I copy across a file (say a film) that has a name like, say "Core Universe.DD+Atmos.m2ts" or "The.Martian.2015.mkv".

When in the Movie list if I press the IMDB button the box crashes.

Log example attached:
View attachment 63741
View attachment 63742
View attachment 63743

will look later!

 

[smipx]

No rush at all - I am not going to be here from now until Tuesday am myself Have a break!!