No up and down possible in Rec,Play& Timeshift submenus

[wawa16]

Yes, 4.3 but also the first releases of 4.4. I also reported to ViX forum without success (their support is not very quick... )
Other images, don't have the same problem but it's not possible to use their .pyo files to fix the problem.
Maybe I'll try again just to see what happens.

Recent updates for OpenVix 4.5.0.015 & Openatv 7.0 & OBH 4.4 That cause this problem..

 

[el bandido]

But:
1) in Zero 4K it also happens in a clean image installed in flash, although only for the Timeshift submenu.
2) It also happens in Duo2 (I didn't report that as well, as I'm no longer sure someone is interested and I'm not paid as well to do these tests ) in a situation where there is only one image installed in OMB.

I know .py are not compiled and .pyo are, but I've just, in another instance, tried to check whether or not I could fix the issue and surely the OATV pyo did (in the "full" image I use in OMB.

To sum up my tries, I tested all my 3 boxes, both from flash and from OMB. This is what happens (I repeat: clean images both in flash or in OMB):
1) Duo2 and Solo4K both perfectly work from flash and not from OMB in both submenus.
2) Zero4K behaves differently (and should tell something by itself): either from flash or from OMB, it works only the Recording submenu whilst the Timeshift one doesn't.

So, it's strange and interesting your analysis about the lack of a call to specific boxes, because (at least me) I had this difference. I'm not a coder, but it must be related to something else.
Thanks for your effort. I repeat: I did my test only with clean images and it was reproducible.
I did not upload the same video about Duo2, but I can assure you that there was only one image installed in OMB.

More, it does not happen to any boxes with OBH 4.3: might it be related to the new python used by ViX 5.4 and 4.4? I don't know: I quit programming many years ago, so I'm noone in the field of programming, nowadays.

Some changes to the keymap.xml file were made in the second month of 2021, I don't know if this is your problem, but it may be worth testing or looking into.
3 lines were added to the keymap.xml around Feb. 8, 2021 as shown in the link:
https://github.com/BlackHole/enigma...c55156f2c4436ffde7a23be21a4b4261dc1035834f182

Attached is a file with those 3 lines deleted. You may test it by by unzipping and installing the attached keymap.xml in the '/usr/share/enigma2" folder of the receiver's file system. Keep your old or original keymap.xml file so you can reinstall it if the edited keymap.xml file does not work or causes unwanted issues.

 

[Alexwilmac]

I tried your keymap in OMB (where the issues exists) and it doesn't change anything.
I believe the problem is, instead, in the pyo files in /usr/lib/enigma2/python/Screens
As I said, I once succeed at fixing at least one submenu, replacing timeshift.pyo file. But then I gave up.

 

[Thomas67]

Do the OMB installation also share the Movie/Timeshift location? In the case of having only one storage device in your box your Default Storage device will become the root (Flash) when booting into OMB and a hidden mount /omb is created
This could be the problem maybe. Even if you can mount the device as /media/hdd it still will have the /omb ref also.

Digg into your drawers and find a USB memorystick. If not already formated as ext4 use device manager to format the stick or the BH USB Format Wizard. Then mount that as Default storage device and see if the problem is gone?

 

[Alexwilmac]

Unfortunately, if it wasn't to the fact that this issue:
a) appeared all of a sudden after of of the first releases of 4.4 (surely after 008) and
b) to the fact it happens also in flash under some models (like Zero4K, as of my post #11) I might think you are right, my friend.
And, also, for a short time, I managed to fix this bug by "stealing" the two files
Recordings.pyo
Timeshift.pyo
from OATV as it was at the time. Then, also this workaround stopped working after other subsequent updates.
But the fact itself it worked for a bit, means the issue is within those two files.
Then if it is due to the sharing of OMB movie location, I don't know.
There is also to add that (in my case, but I don't think is the case of the other users who have starting reporting the same issue, finally) OMB runs from the internal SDD but, I repeat, in Zero4K it happens also from flash and, even more interesting, without any OMB present in that device!

 

[Ev0]

Unfortunately, if it wasn't to the fact that this issue:
a) appeared all of a sudden after of of the first releases of 4.4 (surely after 008) and
b) to the fact it happens also in flash under some models (like Zero4K, as of my post #11) I might think you are right, my friend.
And, also, for a short time, I managed to fix this bug by "stealing" the two files
Recordings.pyo
Timeshift.pyo
from OATV as it was at the time. Then, also this workaround stopped working after other subsequent updates.
But the fact itself it worked for a bit, means the issue is within those two files.
Then if it is due to the sharing of OMB movie location, I don't know.
There is also to add that (in my case, but I don't think is the case of the other users who have starting reporting the same issue, finally) OMB runs from the internal SDD but, I repeat, in Zero4K it happens also from flash and, even more interesting, without any OMB present in that device!

These are the commits that broke it:
https://github.com/OpenViX/enigma2/...082697b9e8a76bc21b103b5f94e4d701adb5e7ce957b5
https://github.com/OpenViX/enigma2/...082697b9e8a76bc21b103b5f94e4d701adb5e7ce957b5

https://github.com/OpenViX/enigma2/...f29a8c9d683ff89edba9abb179dea2408dd0fd5964f7a
https://github.com/OpenViX/enigma2/...f29a8c9d683ff89edba9abb179dea2408dd0fd5964f7a

Feel free to contact the author of these commits (not the person that committed them) on github and ask him to fix them.

Goodluck

 

[Alexwilmac]

Thanks! I didn't manage to contact in PM the commits' author but I commented on them.
Finally... I felt I was talking in the desert Also in the ViX forum, there was no responsible check on this bug.
Thanks for your discovery.

 

[el bandido]

Here is the response that is several days old:
Huevos replied 4 days ago •
This is the expected behaviour if there is no valid device attached. Make certain any device you are going to use for recordings is EXT4 formatted.

Is this information correct? You had no hard drive or valid recording device connected???

 

[Alexwilmac]

I had no time to answer in the ViX forum, as he requested. But no: just and simply reading my detailed posts, it's said that
1) I have a valide device attached.
2) This device (1Tb SSD) is used either as recording/timeshift unit or for OMB.
But this has surely nothing to do with the issue, reported now not only by me but by other users as well, because
a) it had never occurred before a certain update by ViX/OBH
b) because I manage to temporarily fix it by using different .pyo files.
And this was confirmed by Ev0's post, because he found out some modification exactly in Recordings.pyo and Timeshift.pyo.
So, my theory was correct. The issue comes from the modification made to those two files.