View Full Version : [Zgemma H7] HDMI-CEC working with Standby but not working with Deep Standby
Hi all,
I have my Zgemma connected to my Soundbar via HDMI (done like this due to older TV creating lip sync issues when zgemma is connected to that)
The TV is connected to the soundbar via HDMI-ARC
I have enabled HDMI-ARC in the Zgemma and set all the settings as follows:
63643
63644
- When I turn off the Zgemma (Standby) the TV and Soundbar turns off - Good
- When I turn on the Zgemma the TV and Soundbar turn on - Good
- When I select Power -> Deep Standby the Zgemma goes to Deep Standby fine after displaying "Your Zgemma is Shutting down" on teh TV for about 10 seconds but, crucially, the TV and Soundbar remain on. I have to manually power off the TV using the TV remote
- When I power on the Zgemma from Deep Standby the Zgemma wakes up the TV and Soundbar - Good
I checked the logs of HDMI CEC in openvix and the Standby action was logged (see below) but the Deep Standby action did not log anything at all. I prefer to use Deep Standby at night to save power overnight (no recordings overnight) but at the moment the issue is causing me to accidentally leave the TV on all night as the screen goes black when the zgemma goes to deep standby and the TV does not warn you for some time (with an image saying "HDMI no Input Source" and by the time it shows that I may have already left the room.
Can HDMI-CEC be made to work when using Deep Standby via the settings or is this a bug??
I'm on Openvix 5.4.016 (not planing to go to v6 just now as its a big job for me) but am happy to make any little mods as needed to backport any fix if possible...
Many thanks
Paul
HDMI-CEC Log for regular standby:
Tx: 08:59:27 <Give Device Power Status> > 8F [0x0F]
Tx: 08:59:28 <Standby> > 36 [0x00]
Tx: 08:59:28 > 44 6C [0x05]
Tx: 08:59:29 <Standby> > 36 [0x05]
Rx: 08:59:29 <Set System Audio Mode> < 72 00
Rx: 08:59:29 <Report Physical Address> < 84 40 00 05
Rx: 08:59:29 <Standby> < 36
Rx: 08:59:30 <Standby> < 36
Rx: 08:59:30 <Set Menu Language> < 32 eng
Rx: 08:59:30 <Device Vendor ID> < 87 00 00 F0
Rx: 08:59:30 <Device Vendor ID> < 87 00 00 F0
Tx: 08:59:37 <Image View On> > 04 [0x00]
Tx: 08:59:37 <Active Source> > 82 41 00 [0x0F]
Tx: 08:59:37 <Menu Status> > 8E 00 [0x00]
Tx: 08:59:37 > 44 6D [0x05]
Tx: 08:59:37 <System Mode Audio Request> > 70 41 00 [0x05]
Rx: 08:59:38 <Routing Change> < 80 40 00 41 00
Rx: 08:59:38 <Set System Audio Mode> < 72 01
Rx: 08:59:38 <Set System Audio Mode> < 72 01
Rx: 08:59:38 <Set Menu Language> < 32 eng
Rx: 08:59:38 <Device Vendor ID> < 87 00 00 F0
Rx: 08:59:38 < 1A 01
Rx: 08:59:39 <Device Vendor ID> < 87 00 00 F0
Rx: 08:59:39 <Report Physical Address> < 84 40 00 05
Rx: 08:59:39 <Device Vendor ID> < 87 00 00 F0
Rx: 08:59:40 <Report Physical Address> < 84 40 00 05
Tx: 08:59:41 <Image View On> > 04 [0x00]
Tx: 08:59:41 <Active Source> > 82 41 00 [0x0F]
Tx: 08:59:41 <Menu Status> > 8E 00 [0x00]
Tx: 08:59:41 > 44 6D [0x05]
Tx: 08:59:41 <System Mode Audio Request> > 70 41 00 [0x05]
Rx: 08:59:41 <Set System Audio Mode> < 72 01
Rx: 08:59:45 <Give Device Power Status> < 8F
Tx: 08:59:45 <Report Power Status> > 90 00 [0x58]
Perhaps use a power timer to select deep standby.
During normal usage I turn off my box by simply pressing the on/off button which puts the box into standby.
A power timer then kicks in and puts the box into deep standby 10 minutes later.
From what you have written this intermediate standby state would turn off your TV and sound bar
See post 6 and 8
https://www.world-of-satellite.com/showthread.php?63922-startup-to-standby#6
Hi all,
I have my Zgemma connected to my Soundbar via HDMI (done like this due to older TV creating lip sync issues when zgemma is connected to that)
The TV is connected to the soundbar via HDMI-ARC
I have enabled HDMI-ARC in the Zgemma and set all the settings as follows:
63643
63644
- When I turn off the Zgemma (Standby) the TV and Soundbar turns off - Good
- When I turn on the Zgemma the TV and Soundbar turn on - Good
- When I select Power -> Deep Standby the Zgemma goes to Deep Standby fine after displaying "Your Zgemma is Shutting down" on teh TV for about 10 seconds but, crucially, the TV and Soundbar remain on. I have to manually power off the TV using the TV remote
- When I power on the Zgemma from Deep Standby the Zgemma wakes up the TV and Soundbar - Good
I checked the logs of HDMI CEC in openvix and the Standby action was logged (see below) but the Deep Standby action did not log anything at all. I prefer to use Deep Standby at night to save power overnight (no recordings overnight) but at the moment the issue is causing me to accidentally leave the TV on all night as the screen goes black when the zgemma goes to deep standby and the TV does not warn you for some time (with an image saying "HDMI no Input Source" and by the time it shows that I may have already left the room.
Can HDMI-CEC be made to work when using Deep Standby via the settings or is this a bug??
I'm on Openvix 5.4.016 (not planing to go to v6 just now as its a big job for me) but am happy to make any little mods as needed to backport any fix if possible...
Many thanks
Paul
HDMI-CEC Log for regular standby:
Tx: 08:59:27 <Give Device Power Status> > 8F [0x0F]
Tx: 08:59:28 <Standby> > 36 [0x00]
Tx: 08:59:28 > 44 6C [0x05]
Tx: 08:59:29 <Standby> > 36 [0x05]
Rx: 08:59:29 <Set System Audio Mode> < 72 00
Rx: 08:59:29 <Report Physical Address> < 84 40 00 05
Rx: 08:59:29 <Standby> < 36
Rx: 08:59:30 <Standby> < 36
Rx: 08:59:30 <Set Menu Language> < 32 eng
Rx: 08:59:30 <Device Vendor ID> < 87 00 00 F0
Rx: 08:59:30 <Device Vendor ID> < 87 00 00 F0
Tx: 08:59:37 <Image View On> > 04 [0x00]
Tx: 08:59:37 <Active Source> > 82 41 00 [0x0F]
Tx: 08:59:37 <Menu Status> > 8E 00 [0x00]
Tx: 08:59:37 > 44 6D [0x05]
Tx: 08:59:37 <System Mode Audio Request> > 70 41 00 [0x05]
Rx: 08:59:38 <Routing Change> < 80 40 00 41 00
Rx: 08:59:38 <Set System Audio Mode> < 72 01
Rx: 08:59:38 <Set System Audio Mode> < 72 01
Rx: 08:59:38 <Set Menu Language> < 32 eng
Rx: 08:59:38 <Device Vendor ID> < 87 00 00 F0
Rx: 08:59:38 < 1A 01
Rx: 08:59:39 <Device Vendor ID> < 87 00 00 F0
Rx: 08:59:39 <Report Physical Address> < 84 40 00 05
Rx: 08:59:39 <Device Vendor ID> < 87 00 00 F0
Rx: 08:59:40 <Report Physical Address> < 84 40 00 05
Tx: 08:59:41 <Image View On> > 04 [0x00]
Tx: 08:59:41 <Active Source> > 82 41 00 [0x0F]
Tx: 08:59:41 <Menu Status> > 8E 00 [0x00]
Tx: 08:59:41 > 44 6D [0x05]
Tx: 08:59:41 <System Mode Audio Request> > 70 41 00 [0x05]
Rx: 08:59:41 <Set System Audio Mode> < 72 01
Rx: 08:59:45 <Give Device Power Status> < 8F
Tx: 08:59:45 <Report Power Status> > 90 00 [0x58]
1) I will have a look, but the hdmicec routines have been changed significantly for python 3, so changes to python 2(5.4) will take a retrofit perhaps.
2) what is holding you back from V6? - this is a multiboot receiver, so normally backup settings, flash new image to a different slot and restore settings when it finds the backup during initialisation is absolutely easy —— and if you have issues just reboot to the 5.4 image
Hi Both,
The power timer is a good backup option in case I forget to turn the TV off. I'll look in to that.
With regards v6 - the only thing holding me back at the moment is the fact that I have made a lot of my own little modifications to my EPG skin to get it "just so" for me. It took me an age (being a non-programmer). I know that most of the changes were incorporated into the new EPG code (button reassignments etc). but as it was (up to now) all working just fine I did not want to take the leap. I did some mods to fix IMDB and to get rid of the little clock icons either side of a scheduled recording and some changes to the button assignments prior to the above fixes/incorporations etc...
I will upgrade - Promise!! but .... I have to pick a period when the other family members will not mind as I know, from experience, that I will have some days of tweaking to get it "just so" with things like the EPG button updates, Channel 4 HD in the EPG, the Picons, the refreshing of the EPC process, etc.etc. etc.... Having a "window" during Covid and the new "working from home regime" has proved to be a bit tricky.
But - if there is any mod that can make HDMI-CEC kick in when doing deep standby (as a quick and dirty intermin measure) then I would be really happy and grateful :-)
Thanks
Paul
Hi Both,
The power timer is a good backup option in case I forget to turn the TV off. I'll look in to that.
With regards v6 - the only thing holding me back at the moment is the fact that I have made a lot of my own little modifications to my EPG skin to get it "just so" for me. It took me an age (being a non-programmer). I know that most of the changes were incorporated into the new EPG code (button reassignments etc). but as it was (up to now) all working just fine I did not want to take the leap. I did some mods to fix IMDB and to get rid of the little clock icons either side of a scheduled recording and some changes to the button assignments prior to the above fixes/incorporations etc...
I will upgrade - Promise!! but .... I have to pick a period when the other family members will not mind as I know, from experience, that I will have some days of tweaking to get it "just so" with things like the EPG button updates, Channel 4 HD in the EPG, the Picons, the refreshing of the EPC process, etc.etc. etc.... Having a "window" during Covid and the new "working from home regime" has proved to be a bit tricky.
But - if there is any mod that can make HDMI-CEC kick in when doing deep standby (as a quick and dirty intermin measure) then I would be really happy and grateful :-)
Thanks
Paul
I have just tested on my current V6 lounge setup (GBuhd4K into LG TV and Sonos soundbar) and deep standby works perfectly - both TV and soundbar are placed in standby ... so perhaps an incentive to move to V6!
I just can't do it yet :-(
I have half a feeling it used to work fine when I had the Zgemma plugged into the TV but now I have it plugged into the Soundbar it seems to not be able to send the Standby signal to the TV (via the Soundbar) when Deep Standby is selected on the ZGemma - even though the Soundbar to the TV is HDMI-ARC. I think the soundbar cannot handle the "DeepStandBy" in the py and simply drops it ... but does handle and forward the "Standby" in the py to the TV. The TV could (can) obviously understand both and worked in both scenarios.
If that be the case I have 3 choices:
1) Upgrade to v6 and hope that it works (maybe it will - maybe it won't with the soundbar as the "Hub" - but I can test for sure and will report back at some point).
2) Have a spare button to turn off the TV (And Soundbar) - This is what I will do whenever I remember (99.9% of the time - with suitable training for the rest of the household) until I can go to V6.
3) Plug the zgemma back into the TV and suffer some lip-sync problems caused by the TV sending the Audio to the Soundbar after the picture is displayed - This I can't live with and does not happen with the soundbar as the Hub of the operation so will stick to 2) above for now.
I will also activate (reduce) the power saving feature of the TV (to turn itself to standby) if no HDMI signal is recieved for 15 minutes (insead of the Zgemma/OpenVIX power timer) as I think that will work better in my situation. It is 2 hours currently.
Promise to go to v6 as soon as :-)
Thanks
Paul
Sorry fat fingers - please remove this post (not the whole thread).
Hi twol.
OK took the plunge following your hint :-)
Did a backup of settings from 5.4, installed a fresh 6.1.004 onto a spare slot and then restored settings.
S**t that was easy.
On the negative side. The HDMI-CEC is behaving the same. When selecting Deep Standby it is not turning off the Soundbar or the TV (TV's HDMI(ARC) connected to the Soundbar's HDMI(ARC); Zgemma HDMI connected to the Soundbar HDMI 2).
63654
I looked at the logs for HDMI-CEC and this was the output. Action 1 23:29:16 Deep Standby. Zgemma message saying Box was going to go into Deep Standby, Box turned off, TV and Soundbar left on.
Manually turned off TV which also turned off Soundbar and then......
Action 2: 23:29:51 Turn on Zgemma. Booted up and then turned on the TV and the Soundbar.
Tx: 23:29:16 <Give System Audio Mode Stat> 7D [0x05]
Tx: 23:29:16 <Give System Audio Mode Stat> 7D [0x05]
Tx: 23:29:16 <Give System Audio Mode Stat> 7D [0x05]
Tx: 23:29:16 <Give System Audio Mode Stat> 7D [0x05]
Tx: 23:29:16 <Menu Status> > 8E 00 [0x00]
Tx: 23:29:16 <Image View On> > 04 [0x00]
Tx: 23:29:16 <Active Source> > 82 41 00 [0x0F]
Tx: 23:29:16 <Menu Status> > 8E 00 [0x00]
Tx: 23:29:16 <User Control Pressed> > 44 6D [0x05]
Tx: 23:29:16 <System Audio Mode Request> > 70 41 00 [0x05]
Tx: 23:29:51 <Image View On> > 04 [0x00]
Tx: 23:29:51 <Active Source> > 82 41 00 [0x0F]
Tx: 23:29:51 <Menu Status> > 8E 00 [0x00]
Tx: 23:29:51 <User Control Pressed> > 44 6D [0x05]
Tx: 23:29:51 <System Audio Mode Request> > 70 41 00 [0x05]
Rx: 23:29:51 <System Audio Mode Status> < 7E 01
Rx: 23:29:52 <System Audio Mode Status> < 7E 01
Rx: 23:29:53 <System Audio Mode Status> < 7E 01
Rx: 23:29:53 <System Audio Mode Status> < 7E 01
Rx: 23:29:54 <Set System Audio Mode> < 72 01
Rx: 23:29:56 <Set System Audio Mode> < 72 01
Hi twol.
OK took the plunge following your hint :-)
Did a backup of settings from 5.4, installed a fresh 6.1.004 onto a spare slot and then restored settings.
S**t that was easy.
On the negative side. The HDMI-CEC is behaving the same. When selecting Deep Standby it is not turning off the Soundbar or the TV (TV's HDMI(ARC) connected to the Soundbar's HDMI(ARC); Zgemma HDMI connected to the Soundbar HDMI 2).
63654
I looked at the logs for HDMI-CEC and this was the output. Action 1 23:29:16 Deep Standby. Zgemma message saying Box was going to go into Deep Standby, Box turned off, TV and Soundbar left on.
Manually turned off TV which also turned off Soundbar and then......
Action 2: 23:29:51 Turn on Zgemma. Booted up and then turned on the TV and the Soundbar.
Tx: 23:29:16 <Give System Audio Mode Stat> 7D [0x05]
Tx: 23:29:16 <Give System Audio Mode Stat> 7D [0x05]
Tx: 23:29:16 <Give System Audio Mode Stat> 7D [0x05]
Tx: 23:29:16 <Give System Audio Mode Stat> 7D [0x05]
Tx: 23:29:16 <Menu Status> > 8E 00 [0x00]
Tx: 23:29:16 <Image View On> > 04 [0x00]
Tx: 23:29:16 <Active Source> > 82 41 00 [0x0F]
Tx: 23:29:16 <Menu Status> > 8E 00 [0x00]
Tx: 23:29:16 <User Control Pressed> > 44 6D [0x05]
Tx: 23:29:16 <System Audio Mode Request> > 70 41 00 [0x05]
Tx: 23:29:51 <Image View On> > 04 [0x00]
Tx: 23:29:51 <Active Source> > 82 41 00 [0x0F]
Tx: 23:29:51 <Menu Status> > 8E 00 [0x00]
Tx: 23:29:51 <User Control Pressed> > 44 6D [0x05]
Tx: 23:29:51 <System Audio Mode Request> > 70 41 00 [0x05]
Rx: 23:29:51 <System Audio Mode Status> < 7E 01
Rx: 23:29:52 <System Audio Mode Status> < 7E 01
Rx: 23:29:53 <System Audio Mode Status> < 7E 01
Rx: 23:29:53 <System Audio Mode Status> < 7E 01
Rx: 23:29:54 <Set System Audio Mode> < 72 01
Rx: 23:29:56 <Set System Audio Mode> < 72 01
Great!: ... but bad!
Now in my setup, both sat receiver (hdmi1) and soundbar(hdmi-ARC) are attached to the TV directly, your diagram indicateś everything goes via the soundbar, so that seems to be the issue.
Just noticed that you have detect next boxes before standby - can you disable, that's possibly why its not sending the power off (in standby it doesn't check this)
To be honest I hate the hdmicec log, but anyway I need to see the debug log, from power up (from deep standby), to return to deep standby - so if you could post that and lets see if the disable will fix the issue.
If not can you stop the box (init 4 in putty), rename /usr/lib/enigma2/python/Components/HdmiCec.pyc to something and copy attachment over, then init 6 in putty........ post debug log
Hi there, Is it the same log I have been sending that you need? If not then please let me know what log and if any extra debugging settings need to be turned on. I agree - the log from HDMI-CEC is a little "odd" and I could not make any sense of it at all :-)
If so I will do that asap.
You are right - the setup is not the most common (using the Soundbar as the hub of the operation) but I attahed the image just to demonstrate that it is meant to be a valid setup.
Bit of history as to why I am where I am....
What this setup does is allow the sound to be processed by the "sound processor" without letting the TV touch and mess up / do a poor job of passthrough / downmix / screw with the audio (which, amongst other worse things, can add delay/advance to the sound and affect the sync of the video and audio). We are only talking a few ms of issue with the TV forwarding the sound to the bar (when the TV is the hub of the operation) but I was noticing issues as the audio track from the Zgemma differs depending on whether its a downloaded file/stream (any of DTS,EC3/DD E-EC-3/DD+), a satellite broadcast (AC3) or a Freeview broadcast (PCM) some were perfectly in sync and some had a negative delay (which the TV and soundbar cant control as you can only delay the autio and not advance it) which was driving me nuts.
As soon as the soundbar was made the hub it all went away. All set to "passthrough" of course. The soundbar then does a fine job of sending the Video to the TV and keeping it all in sync (mostly). Having just spent a big "bag of sand" on a new soundbar I was not going to put up with crappy downmixed PCM all the time (with a fixed advance on the sound using the Audio settings on the Zgemma).
I hope this helps. This is prior to swapping the pyc with the py.
All cases.... detect next boxes before standby DISABLED
-------------------------------------------------------------------------------------
Normal Resume from Standby.... Go to Standby - ALL WORKING FINE TV turns off and Soundbar turns off
Tx: 09:40:56 <User Control Pressed> > 44 43 [0x05]
Tx: 09:40:56 <User Control Released> > 45 [0x05]
Tx: 09:41:00 <Give Device Power Status> > 8F [0x0F]
Tx: 09:41:01 <Standby> > 36 [0x00]
Tx: 09:41:01 <User Control Pressed> > 44 6C [0x05]
Tx: 09:41:01 <Standby> > 36 [0x05]
Rx: 09:41:01 <Set System Audio Mode> < 72 00
Rx: 09:41:02 <Standby> < 36 00
Rx: 09:41:02 <Report Physical Address> < 84 40
Rx: 09:41:02 <Standby> < 36 40
Tx: 09:41:36 <Image View On> > 04 [0x00]
Tx: 09:41:36 <Active Source> > 82 41 00 [0x0F]
Tx: 09:41:36 <Menu Status> > 8E 00 [0x00]
Tx: 09:41:36 <User Control Pressed> > 44 6D [0x05]
Tx: 09:41:36 <System Audio Mode Request> > 70 41 00 [0x05]
Rx: 09:41:37 <Report Physical Address> < 84 40
Rx: 09:41:38 <Routing Change> < 80 40
Rx: 09:41:38 <Set System Audio Mode> < 72 01
Rx: 09:41:38 <Set System Audio Mode> < 72 01
Rx: 09:41:38 <Set Menu Language> < 32 65
Rx: 09:41:38 <Reporting Device Vendor ID>< 87 00
Rx: 09:41:38 <Reporting Device Vendor ID>< 87 00
Tx: 09:41:39 <Image View On> > 04 [0x00]
Tx: 09:41:39 <Active Source> > 82 41 00 [0x0F]
Tx: 09:41:39 <Menu Status> > 8E 00 [0x00]
Tx: 09:41:39 <User Control Pressed> > 44 6D [0x05]
Tx: 09:41:39 <System Audio Mode Request> > 70 41 00 [0x05]
Rx: 09:41:41 <Set System Audio Mode> < 72 01
Rx: 09:41:45 <Give Device Power Status> < 8F 00
Tx: 09:41:45 <Report Power Status> > 90 00 [0x00]
Rx: 09:41:46 <Report Physical Address> < 84 40
Rx: 09:41:47 <Set System Audio Mode> < 72 01
Rx: 09:41:49 <Vendor Command With ID> < A0 00
Rx: 09:41:54 <Reporting Device Vendor ID>< 87 00
Rx: 09:41:55 <Report Physical Address> < 84 40
Tx: 09:42:00 <Give Device Power Status> > 8F [0x0F]
Tx: 09:42:01 <Standby> > 36 [0x00]
Tx: 09:42:01 <User Control Pressed> > 44 6C [0x05]
Tx: 09:42:01 <Standby> > 36 [0x05]
Rx: 09:42:01 <Set System Audio Mode> < 72 00
Rx: 09:42:02 <Report Physical Address> < 84 40
Rx: 09:42:02 <Standby> < 36 00
Rx: 09:42:02 <Standby> < 36 00
Resume from Deep Standby (All devices off at beginning) then into Deep Standby - NOT WORKING TV & Soundbar left on:
Tx: 09:49:28 <Give System Audio Mode Stat> 7D [0x05]
Tx: 09:49:28 <Give System Audio Mode Stat> 7D [0x05]
Tx: 09:49:28 <Give System Audio Mode Stat> 7D [0x05]
Tx: 09:49:28 <Give System Audio Mode Stat> 7D [0x05]
Tx: 09:49:28 <Menu Status> > 8E 00 [0x00]
Tx: 09:49:28 <Image View On> > 04 [0x00]
Tx: 09:49:28 <Active Source> > 82 41 00 [0x0F]
Tx: 09:49:28 <Menu Status> > 8E 00 [0x00]
Tx: 09:49:28 <User Control Pressed> > 44 6D [0x05]
Tx: 09:49:28 <System Audio Mode Request> > 70 41 00 [0x05]
Tx: 09:52:05 <Image View On> > 04 [0x00]
Tx: 09:52:05 <Active Source> > 82 41 00 [0x0F]
Tx: 09:52:05 <Menu Status> > 8E 00 [0x00]
Tx: 09:52:05 <User Control Pressed> > 44 6D [0x05]
Tx: 09:52:05 <System Audio Mode Request> > 70 41 00 [0x05]
Rx: 09:52:08 <Routing Change> < 80 40
Rx: 09:52:09 <Set System Audio Mode> < 72 01
Rx: 09:52:09 <Give Deck Status> < 1A 01
Rx: 09:52:09 <Set System Audio Mode> < 72 01
Rx: 09:52:10 <Reporting Device Vendor ID>< 87 00
Rx: 09:52:10 <Set Menu Language> < 32 65
Rx: 09:52:10 <Reporting Device Vendor ID>< 87 00
Rx: 09:52:11 <Set System Audio Mode> < 72 01
Rx: 09:52:14 <Give Device Power Status> < 8F 00
Tx: 09:52:14 <Report Power Status> > 90 00 [0x00]
Rx: 09:49:46 <Vendor Command With ID> < A0 00
Rx: 09:49:52 <Reporting Device Vendor ID>< 87 00
Rx: 09:49:52 <Report Physical Address> < 84 40
Tx: 09:49:52 <Standby> > 36 [0x00]
Tx: 09:49:52 <User Control Pressed> > 44 6C [0x05]
Tx: 09:49:52 <Standby> > 36 [0x05]
I have now replaced the pyc with the py and here is the HDMI-CEC log (attached)63658
also attached the full enigma2 debug log (if it helps in any way) 63659
Just in case it is relevant. The TV is a Samsung (UE49MU7000) and the Soundbar is a Samsung (HW-Q700A)
I know --- I'm not a samsung Fanboy - Honest - It was a really really good offer for the Q700A and my naive assumption was that it would all work together "better" if it was all Samsung. This is despite no end of little niggles with the TV over the years... Turns out that Samsung are a law unto themselves.
Both are on the latest Firmware.
OK, many thanks.
1. can you change debug log default to local time ... much more readable for old guy like me!
2. the debug log shows boot up from standby? deepstandby? ..............upto just loading up from epgcache , there is no termination of any description.
3. the box at boot up sees the hdmicec address change and automatically resets it, so can you try resetting the address in hdmicec setup to 0.0.0.0 and just check it all still works - I don't expect that to fix the issue, but .....
So can you give me a debug log (local time), from out of standby or deepstandby -------> to deep standby
Lastly did you reset the detect next boxes before standby to No in setup?? I should see in the debug log, but never hurts to ask!
Hi there.
Originals were Going to Deep Standby to start the test then from Deep Standby to ON and then from ON to Deep Standby
I did reset the "detect next boxes before standby" to No in setup
Time now set to real..
The logs below are without any change to address of HDMI-CEC 0.0.0.0 ( I will do that in a little while and can test again).
With this log I went into deep standby (to get to the start of the testing cycle (start the test from Deep Standby). Turned the TV off and Soundbar off.
I then from the Box in DS turned the box on (approx 12:57)
TV Came on, Soundbar came on all Good....
Gave it a few minutes and then at approx. 13:02 with everything on, I selected Deep Standby from the Power menu. Box told me it was going to DS but TV left on and Soundbar left on. I then powerd off the TV with its remote and the TV and Soundbar both turned off. 63660
Here are the Debug logs from the same time.
6366163662
Hope that all makes sense??
Thanks
Paul
For completeness. Here are my current CEC settings. I have been fiddling with them to try and get it working but this is how they are right now. Set address to 0.0.0.0 as well.
6366363664
As an aside this is not good from Samsung
13:03:36.5808 [HdmiCec][messageReceived0]: msgaddress=112 CECcmd=<Standby>, cmd=36, ctrl0=0, length=1
13:03:36.5817 [HdmiCec][messageReceived1a]: msgaddress > 15 reset to 0
Should be between 0 ---> 15
Also can you copy attachment ConfigEntryTest.py to /usr/lib/enigma2/python/Components/Converter (please rename existing .pyc first as I haven't tested this change ... but its causing a crash)
... and hdmicec.py to /usr/lib/enigma2/python/Components
If you have the time and patience can you do debugs going into Standby and also deepStandby
thanks
I will do this tomorrow twol of that is okay. My wife is getting a bit irate at the lack of TV :-)
I also had a new broadband router/hub today so have been taking the internet off and on all day.
I am not popular in the smipx household but tomorrow is another day and it will all be forgiven overnight ;-)
When I copy these over and reboot does the statement "but its causing a crash" mean that my machine will crash ??
Cheers
Paul
Hi,
Did the py changes (both of them) rebooted and did some more tests.
Wife getting really annoyed now so going to stop further tests tonight and will pick up again 2mo :-)
Timeline (approx times):
Zgemma Action
16:48 Zgemma to Standby - TV and Soundbar both turned off GOOD
16:49 Zgemma Power on - TV and Soundbar both turned on GOOD
Put soundbar into mute using TV remote
16:50 Zgemma to Deep Standby - Zgemma turned off, clock dissapeared and hard drive stopeed spinning - TV and Soundbar both remained on
16:51 Used TV remote control to turn off TV (Zgemma still in deep standby at this stage)
Noticed that the Zgemma HDD span up for about 10 seconds and then went off again
16:52 Power On Zgemma from DS - TV and Soundbar both turned on GOOD
Hope that all makes sense.
636746367563676
I will do this tomorrow twol of that is okay. My wife is getting a bit irate at the lack of TV :-)
I also had a new broadband router/hub today so have been taking the internet off and on all day.
I am not popular in the smipx household but tomorrow is another day and it will all be forgiven overnight ;-)
When I copy these over and reboot does the statement "but its causing a crash" mean that my machine will crash ??
Cheers
Paul
Thats absolutely fine, you and yours have shown great patience!
There is a skin crash in the log during Standby and I just want to avoid it while we are fixing the hdmicec issue.
I am out until mid afternoon tomorrow, as I have to be in Munich from early morning, so plenty of time!
I did it anyway. No rush...... results in post #20
sent you a pm too....
If you are in the UK - Have a good flight
If you are taking a ferry - Good luck with that
If you are already on the EU mainland then ignore me!
If you are in the UK - Have a good flight
If you are taking a ferry - Good luck with that
If you are already on the EU mainland then ignore me!
The latter!
Just regarding "There is a skin crash in the log during Standby" is this someting I have done by resoring my settings? I did a few mods myself to the confluence skin in the previous version of openvix and am worried that my tweaks may have carried over to the new release with my restore and be causing the crash somehow.
If not then I will wait for an update to the confluence skin in due course :-)
If not then I will wait for an update to the confluence skin in due course :-)
If it's the ViXBMC_1080_Confluence skin, then I reckon there haven't been any updates for 3 years.
:-( Oh such a shame. It's a lovely skin and I've been using it and been happy with it for a long time. Is it the same casae for the Bello Skin - not liking bellow quite as much but its essentially the same just a bit "purple".
I will just stick with confluence and live with the occasional crash in standby I guess.
Here are a few skins... https://github.com/OpenViX/skins/tree/9f57c4633243643f2a412a1dfa21f95044e08f75/src/skins/1080
Yea, Tried most of them - Keep coming back to ViXBMC_1080_Confluence
Sad - I know. but once you get used to one ............
If it's the ViXBMC_1080_Confluence skin, then I reckon there haven't been any updates for 3 years.
Where is the crash?
@smipx - this change is a bit of a hammer job, but just want to see if it fixes the issue for you. Still, shuts down my setup on Standby or DeepStandby, so lets see!
Not entirely sure @Huevos. @Twol mentioned it in post #24 as he's analysed my logs already so he might be able to shed some light at some point. I think he's tied up today / tomorrow but I'm sure he'll reply when he gets a chance.
thanks
Paul
Hi twol,
Installed the latest py file and rebooted.
Then did a go to Deep standby at approx 17:13 - nothing changed - TV left on still (and Soundbar)
turned TV off manually
17:14 turned on zgemma (resume from deep standby
Logs attached:636916369263693
Sorry for the bad result :-(
Can you let Huevos know where the skin was crashing if poss??
Hi twol,
Installed the latest py file and rebooted.
Then did a go to Deep standby at approx 17:13 - nothing changed - TV left on still (and Soundbar)
turned TV off manually
17:14 turned on zgemma (resume from deep standby
Logs attached:636916369263693
Sorry for the bad result :-(
Can you let Huevos know where the skin was crashing if poss??
posted Huevos .....
@smipx .... so try this.
stop box, (init 4) rename .pyc and then copy attachment to /usr/lib/enigma2/python/Screens
reboot (init 6)
Hi twol,
Don't get angry :-) I did it and it didn't make any difference
Timeline:
9.58 Resume DS - TV came on on Soundbar Came on
9:59 - DS on Zgemma - TV Left On and SB Left on
10:00 Turn off TV with TV remote
10:01 Resume from DS - TV came on and SB came on
10:02 Zgemma into normal StandBy - Tv went off and SB went off
10:03 Resume from normal SB - TV came on SB came on
Logs:
63700
63701
63702
63703
Thanks for all the hard work :-)
I have been quietly following this thread as I didn't have time to do any testing.
My H7S is able to put my amp into standby correctly and bring it back out of standby. Also when "Regard deep standby as standby" is enabled it functions as expected so the problem may be the sound bar. Have you tried updating the firmware on it? There is an update dated 5th January, there is no changlog so I've no idea what it fixes/improves.
Edit: Using Vix 6.1.004 (release) with no modification to the hdmicec.py file
Also another thing you can try seeing as you changed the connection layout of the devices is to disable HDMICEC on ALL DEVICES and reboot all of them. Then re-enable it. HDMICEC is flaky at the best of times and the system may be confused with conflicting addresses.
Hi ronand,
Yes the Soundbar was updated to the latest FW when I installed it. It's on 1010.1 The TV is also on the latest.
The odd thing is that it is fine when the Zgemma goes to "standby" rather than "deep standby" so I imagine that if the Zgemma sent a "standby" signal when asked to "deep standby" (exactly the same as it does when a "standby" is requested) then the Soundbar should work well with it. My guess (and only a guess here) is that the py file sends a different command (or in a different way) to the Soundbar when you select "Deep Standby" as opposed to "Standby". Can't see why it would want to do anyting different (if intentional) as its the Zgemma we are asking to go into "Deep Standby" so the command sent to the downstream devices ought to be the same to tell them to go to "Standby".
Probably a massive oversimplification (having taken a look at the py file - Somewhat complex is a bit of an understatement - well for me anyway).
When I changed the connectivity I completely reset the TV with no devices plugged in and follwed the Samsung guide on setting it all up from scratch (in case it could have been causing the issue).
Cheers,
Paul
@smipx, So a question, which plugins do you have installed?
The issue is not the hdmicec code the commands are issued to the C++ hdmicec driver - but it never sends them - so either the box dies very quickly when you have sent deepstandby or there is another issue.
The fact that ronand's h7s works fine, implies the latter.
The last code (I had already tried treating deepstandby like standby) was to bring forward as earliest as possible the code in the Standby routine - and again the hdmicec driver calls are not run.
So this latest update issues the hdmicec driver calls direct from DeepStandby on a broadcast - so all devices on hdmi should see them.
If they don't appear in the log, then there is a block somewhere
There is an issue with Samsung, in so far as the msgaddress used on sends from the Samsung are all over the place, they obviously use a register that is not directly initialised and send whatever value is there at the time.
If this doesn't work, then there is an issue on your image, but don't know what.
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?
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 :-))))))
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.
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 :-)
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:
63708
63709
63710
Cheers,
Paul
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:
63708
63709
63710
Cheers,
Paul
that 2nd log only shows upto 15.15 ....> standby pressed
My bad
Here are a couple of subsequent logs that should complete the picture..
63711
63712
OK - will have a look at cleaning up the standby code
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 ?
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
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
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!
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.
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:
63728
63729
63730
63731
63732
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:
63728
63729
63730
63731
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
I'm in your hands twol.
Whatever you think is the best solution will be fine by me.
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
63734
63735
63736
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:
63741
63742
63743
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
63734
63735
63736
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:
63741
63742
63743
will look later!
No rush at all - I am not going to be here from now until Tuesday am myself :-) Have a break!!
The IMDb problem, most likely is the plugin is creating a junk regex.
The timeshift problem should be fixed with the attached python file (goes in /usr/lib/enigma2/python/Components and reboot).
Iv done all that before it dose not work like I sed I’ll wait till there is a manual update thanks any way
Hi Huevos. Many thanks for that fix. Is what deltec says meaning that it is not woth implementing this fix at this time ???
... I think @deltec posted in the wrong thread.
Well ive put it in anyway and will report back - probably Tuesday as I am away for a bit tonight.
Well ive put it in anyway and will report back - probably Tuesday as I am away for a bit tonight.
when you get back try this attachment for the imdb issue (rename existing plugin.pyc first)
copy attachment to /usr/lib/enigma2/python/Plugins/Extensions/IMDb and reboot as normal procedure
Hi Huevos and twol.
The TimeShift issue seems to be fixed with the VariableValue.py file.
The plugin.py did not fix the IMDb isse :-(
Logs attached.
Thanks
Paul
63758
63759
63760
63761
63762
63763
With regards to the errors in the ViXBMC_1080_Confluence skin. Who would be the right person to beg to make some updates to this to make it stable again for 2022??
It would be a shame to see such a nice skin fall by the wayside.
Thanks
Paul
Hi Huevos and twol.
The TimeShift issue seems to be fixed with the VariableValue.py file.
The plugin.py did not fix the IMDb isse :-(
Logs attached.
Thanks
Paul
63758
63759
63760
63761
63762
63763
Would help if I could spell... new attachment
That did it :-)
Now.... If you could get teh Zgemma to xfer TrueHD Audio + Atmos then that will be it ta.
(only joking)
That did it :-)
Now.... If you could get teh Zgemma to xfer TrueHD Audio + Atmos then that will be it ta.
(only joking)
Can you give me the debug log from a couple of searches or whatever you use imdb for —- I need to do some checks
Here you go :-)
The IMDB no longer crashes but...... it does not shaow any information either ha ha...
I searched for "The Martian.mkv" - downloaded file renamed from "The.Martian.1080p.bla.bla.bla"
"The Midnight Sky.mkv" renamed from someting like "The.Midnight.Sky.20xx.DL.xyz.abc.HD.mkv"
A Lake District Farm Shop - recording from zgemma
All returned no data but the box kept running.
Hope that helps.
63767
Here you go :-)
The IMDB no longer crashes but...... it does not shaow any information either ha ha...
I searched for "The Martian.mkv" - downloaded file renamed from "The.Martian.1080p.bla.bla.bla"
"The Midnight Sky.mkv" renamed from someting like "The.Midnight.Sky.20xx.DL.xyz.abc.HD.mkv"
A Lake District Farm Shop - recording from zgemma
All returned no data but the box kept running.
Hope that helps.
63767
Thats really why I wanted the debug!
The TimeShift issue seems to be fixed with the VariableValue.py file.Can you try again with this file. Get debug log. Code is as original so you should be able to get it to crash. Just want to confirm the previous fix is correct.
Here you go :-)
The IMDB no longer crashes but...... it does not shaow any information either ha ha...
I searched for "The Martian.mkv" - downloaded file renamed from "The.Martian.1080p.bla.bla.bla"
"The Midnight Sky.mkv" renamed from someting like "The.Midnight.Sky.20xx.DL.xyz.abc.HD.mkv"
A Lake District Farm Shop - recording from zgemma
All returned no data but the box kept running.
Hope that helps.
63767
try this version plus debug please
I will try both tomorrow and post back...
Huevos - installed the last variablevalue file and I can#t get TS to crash at the moment. will keep trying and when it does will post a log.
Can you double check that the file is the one you intended me to put back on to allow the crash again?
twol - installed the latest imdb extension and still not any output. Logs attached.
63771
63772
twol - installed the latest imdb extension and still not any output. Logs attached.
63771
63772
Somehow I was using an older version, anyway try this attachment.........
Huevos - installed the last variablevalue file and I can#t get TS to crash at the moment. will keep trying and when it does will post a log.
Can you double check that the file is the one you intended me to put back on to allow the crash again?
Yes the file in post #74 is the correct one.
Yes the file in post #74 is the correct one.
Hi, In that case it is magically fixed as I now can't make timeshift crash !!
I will keep trying and as soon as it does (if it does) I will send you a log file.
Can you try again with this file. Get debug log. Code is as original so you should be able to get it to crash. Just want to confirm the previous fix is correct.
That worked :-)
Debug log attached:
63775
Thanks for the efforts :-)
Paul
That worked :-)
Debug log attached:
63775
Thanks for the efforts :-)
Paul
There is no crash in that log. I need the log with the crash.
@smipx can you try file in post#79 …. For imdb search
@smipx can you try file in post#79 …. For imdb search
Twol - That is what I did and the results for you are in post #82 - I referenced Huevos' quote in that post but I was talking about your plugin.py in post #79. Sorry for the confusion.. The IMDB is fixed and you have the debug log showing that in post #82
Huevos - I have already done that for you - my system has the post #74 variablevalue. Post #81 explains that I could not get it to crash for you so no crash log. I will keep trying and as soon as the Timeshift does crash (if it does) I will post a crash log.
Twol - That is what I did and the results for you are in post #82 - I referenced Huevos' quote in that post but I was talking about your plugin.py in post #79. Sorry for the confusion.. The IMDB is fixed and you have the debug log showing that in post #82
Huevos - I have already done that for you - my system has the post #74 variablevalue. Post #81 explains that I could not get it to crash for you so no crash log. I will keep trying and as soon as the Timeshift does crash (if it does) I will post a crash log.
@smipx - OK, many thanks for all the testing
Huevos - I have already done that for you - my system has the post #74 variablevalue. Post #81 explains that I could not get it to crash for you so no crash log. I will keep trying and as soon as the Timeshift does crash (if it does) I will post a crash log.File in post #74 is the original plus some debug so should do whatever the original did. Maybe just leave it in place and wait for the next crash.
File in post #74 is the original plus some debug so should do whatever the original did. Maybe just leave it in place and wait for the next crash.
I wonder if the mere action of outputting debug in the file is adding some tiny delay to the processing that is stopping the crash??
Like a quark - the mere activity of observing the quark can change its behavior.
No, it was an overflow error.
Oh - Okay - but the theory sounded good :-)
Hi Huevos,
After much playing I managed to get TS to crash once today. I cannot say what precice actions casued it as I did many Pause, Stop, etc, etc....
Logs attached.
63779
63780
63781
Thanks
Paul
So max possible value for a 32 bit integer is:
31**2-1 = 2147483647
Your value at the crash is 2202592220, so out of range.
Not sure where the bad value is coming from so the best way to avoid the crash is force it back in range.
? Is that something I am expected to do ?
Do you need any more logs huevos?
It crashed again but I suspect you have all you need now :-)
Also, With all of these excellent fixes implemented will I need to do anyting other than upgrade to the next release when it is available (with the 3 fixes - HDMICEC, Timeshift and imdb). Will that simply overwrite the temporary fixes I have installed?
Cheers,
Paul
Also, With all of these excellent fixes implemented will I need to do anyting other than upgrade to the next release when it is available (with the 3 fixes - HDMICEC, Timeshift and imdb). Will that simply overwrite the temporary fixes I have installed?
Cheers,
Paul
I would backup settings and online flash into a new slot. Then you could always flip back if necessary
What are the .py rules nowadays if you leave them lying around and then do a software update?
Do they recompile and overwrite more up-to-date .pyc files?
(I know that the next release is likely to be 6.2, so software updates won't be an option, just wondering.)
What are the .py rules nowadays if you leave them lying around and then do a software update?
Do they recompile and overwrite more up-to-date .pyc files?
(I know that the next release is likely to be 6.2, so software updates won't be an option, just wondering.)
If you install a .py file OPKG knows it did not install it, so won't remove it before the upgrade. For people testing with .py it is always a good idea to flash and restore.
Hi Twol,
I have another question for you (being the resident HDMI-CEC guru) if you don't mind?
I just got a Kodi media player (OSMC Vero 4K+) and an HDMI Switch will soon be on the way (that is CEC compliant) - Amazon ASIN B0928XP25L. I plan to have both the Zgemma and the Vero plugged into the switch and then the switch plugged into the Soundbar. The Soundbar will then relay the picture to the TV. I will then watch the zgemma most of the time and on the odd occasion press the switch to flip over to the Vero. I must have the Vero plugged into the Soundbar and would want the Zgemma plugged into the Soundbar too (but only 1 spare input HDMI) as:
1. The Zgemma has the lip sync issue if plugged into the TV
2. The Vero will be passing FULL-HD and ATMOS so must be plugged into the bar.
I want to make sure the TV and Soundbar don't get their knickers in a twist when I flip over and was wondering if I should give the zgemma a different fixed CEC address (as opposed to 0.0.0.0) so that it is clearly distinguishable from the Vero. I could then flip over and hopefully the TV and Soundbar will always realise that the device is a different device.
Your thoughts on this would be appreciated. Please bear in mind my understanding of how the CEC addressing works is pretty non existent.
Hi Twol,
I have another question for you (being the resident HDMI-CEC guru) if you don't mind?
I just got a Kodi media player (OSMC Vero 4K+) and an HDMI Switch will soon be on the way (that is CEC compliant) - Amazon ASIN B0928XP25L. I plan to have both the Zgemma and the Vero plugged into the switch and then the switch plugged into the Soundbar. The Soundbar will then relay the picture to the TV. I will then watch the zgemma most of the time and on the odd occasion press the switch to flip over to the Vero. I must have the Vero plugged into the Soundbar and would want the Zgemma plugged into the Soundbar too (but only 1 spare input HDMI) as:
1. The Zgemma has the lip sync issue if plugged into the TV
2. The Vero will be passing FULL-HD and ATMOS so must be plugged into the bar.
I want to make sure the TV and Soundbar don't get their knickers in a twist when I flip over and was wondering if I should give the zgemma a different fixed CEC address (as opposed to 0.0.0.0) so that it is clearly distinguishable from the Vero. I could then flip over and hopefully the TV and Soundbar will always realise that the device is a different device.
Your thoughts on this would be appreciated. Please bear in mind my understanding of how the CEC addressing works is pretty non existent.
I am assuming that your soundbar will act like my amp/receiver…….in so far as the amp sends the sat receiver (whichever that box may be) the hdmi cec address which depending on the hdmi port is 1101 —-> 1107. So bottom line for the moment don‘t change theCEC address.
Also until its operating, hard to say how good the hdmicec handshaking will be between the Vero & soundbar.
So I think this will be a case of seeing what happens and what can be fixed if there are issues and maybe dependent on whether the switch can be seen as multiple ports by the soundbar
Hi,
Thanks for that. I will report back if I get any issues and take it from there :-)
File in post #74 is the original plus some debug so should do whatever the original did. Maybe just leave it in place and wait for the next crash.
Hi Huevos, The crash in the TimeShift happened again (finally) - sorry for the long delay!!
It seems that if I pause and then stop and then change channel and pause again it seems to pretty consitently make the box crash.
Note that in order to be allowed to Pause a second time (in any scenario) I have to press stop (twice) until I get a little red X and then I can pause again. Without that step the 2nd time I try to pause it does nothing. I reported that ages ago and just learned to live with it (so not a problem) but I wanted to let you know so you can see the presses happening in the logs and don't wornder why they are there.
Logs attached:
63821
63822
Thanks
Paul
Hi Huevos, The crash in the TimeShift happened again (finally) - sorry for the long delay!!
It seems that if I pause and then stop and then change channel and pause again it seems to pretty consitently make the box crash.
Note that in order to be allowed to Pause a second time (in any scenario) I have to press stop (twice) until I get a little red X and then I can pause again. Without that step the 2nd time I try to pause it does nothing. I reported that ages ago and just learned to live with it (so not a problem) but I wanted to let you know so you can see the presses happening in the logs and don't wornder why they are there.
Logs attached:
63821
63822
Thanks
Paul
You need to online flash latest build, it should handle that issue
hi Twol,
Does the latest online patch also include all of your HDMI-CEC fixes and Standby fixes?
hi Twol,
Does the latest online patch also include all of your HDMI-CEC fixes and Standby fixes?
Yes……..………….
OK Cool. I will do that over the weekend then :-)
hi Twol,
I just did a full backup of my image and then did a check for online updates. It tild me there were no updates.
63827
My system information tells me:
63826
There are no updates for 6.1, the next release will be 6.2
Ah Okay. Thanks for clarifying. I can't find that in the downloads so I assume it is not released yet so there is nothing for me to do at this point.
Ah Okay. Thanks for clarifying. I can't find that in the downloads so I assume it is not released yet so there is nothing for me to do at this point.
Backup settings and online flash using ImageManager, much safer (in my view) than software update
Backup settings and online flash using ImageManager, much safer (in my view) than software update
So are you saying there is a newer (general release/stable) image than I currently have to install right now? I can't see one?
Please wait for 6.2 as stated above.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.