Front Panel Icons Fixed.

[Leader]

All done and programmed and compiled working great just how the box should do. going to test the box works on wakeup to record function. if all ok.I will try and get a zip file on here next couple of days.

[Leader]

Find attached file to upgrade to get the Front Panel Icons working when recording.

[birdman]

Thanks. I'll give it a try.
Is the source available anywhere - and an you get it into the standard Enigma2 codebase (so it will come along with standard updates...)?

[Larry-G]

Thanks. I'll give it a try.
Is the source available anywhere - and an you get it into the standard Enigma2 codebase (so it will come along with standard updates...)?

Not likely in my opinion, as has been said multiple times these should be fixed in the drivers by the manufacturers not by hacking the image to compensate.

[rossi2000]

you can de-compile the pyo to look at the source.
but im not sure whats been changed atm, or even if this file is from vix image

[birdman]

I couldn't see the difference between the 1 and >1 recording icons when I started up 1 then another recording.
But it turned out that this was because I already had one running and was actually looking at 2 and 3 recordings! Once I stopped my 2 test ones I could see it.

Looks OK. It honours the setting as to whether display FP icons, which I had to switch on, hence the not-noticing that I already had a recording running when I restarted the GUI. So I've missed a bit of "I'm Sorry I haven't a Clue" (rather appropriate :)), but can always get it on Saturday should I wish.

[birdman]

Not likely in my opinion, as has been said multiple times these should be fixed in the drivers by the manufacturers not by hacking the image to compensate.So is there any documentation available for the manufacturers to see what Enigma2 expects of the drivers?

[Larry-G]

Not as far as I am aware, it's all pretty much in Andy Blacks head sadly. but he has said time and time again that things like this should be handled in the drivers, and we have in the past kept to that standard and other manufacturers have indeed corrected their drivers as a result.

[Leader]

This was so easy to program with a little change of code all the recordtimer needed to do was tell the box what it was doing.

[birdman]

This was so easy to program with a little change of code all the recordtimer needed to do was tell the box what it was doing.Which strikes me as what should be done. Al that the FP driver needs to do is to show/not show the icon as it is told. It should be up to enigma to know the current state and, on any state change set the driver to the current state.

PS: This new code is still looking good. The record icon no longer comes on just because the box comes out of standby.

[Leader]

The only time the boot icon comes on now which was always present is from a restart of the box as that code which switches it on is in the config file which I have not changed, but once your first recording starts and ends it will clear the display which is all we was looking for.

[birdman]

but once your first recording starts and ends it will clear the display which is all we was looking for.Well, it also seems to stop the record icon from coming on when it comes out of Standby, which is what caused me to switch it off entirely (as once you brought it out of Standby it was permanently on).

[Leader]

The file is from an OpenVix image it was off my miracleboxbox running vix 090 image the latest one. I de-compiled the file and added little code then let the box compiled the source code back.

[Leader]

you can de-compile the pyo to look at the source.
but im not sure whats been changed atm, or even if this file is from vix image

The file is from an OpenVix image it was off my miracleboxbox running vix 090 image the latest one. I de-compiled the file and added little code then let the box compiled the source code back.

[birdman]

OK. There is one problem I see.
The record icon still stops when it goes into Standby.

[Rob van der Does]

So is there any documentation available for the manufacturers to see what Enigma2 expects of the drivers?
Hehe, manufacturers should be very well aware of the requirements at the very moment they decide to sell E2-compatible boxes.
And apart from knowing; it's easy enough for themselves to test. Which is what they (should) do before any driver release.

[birdman]

Hehe, manufacturers should be very well aware of the requirements at the very moment they decide to sell E2-compatible boxes.But how, if it isn't documented anywhere? Guess work?

And apart from knowing; it's easy enough for themselves to test. Which is what they (should) do before any driver release.In order to test something you need to have requirements. Someone should know what these are.

[Rob van der Does]

You really should ask manufactures about that. They are the ones who find a good (selling) cause for making boxes E2-compatible.
If they can't, for whatever what reason, they should refrain from doing that.

[birdman]

You really should ask manufactures about that.But I can't, as I have no idea who the manufacturer is. All I know is that the vendor is WoS (and in Europe, I only need to deal with the vendor). So I'm asking them via the only means available. and getting nowhere.
And even if I did know who the vendor is, I wouldn't know what to ask them, as there appears o be no information as to what the FP should be doing anyway.

[Rob van der Does]

So simply believe us, when we say things need to be fixed in drivers. And the only one who can do that, is the manufacturer.
And as he's the one who gains money out of selling E2-compatible boxes, don't let his worries become yours :)

But I agree with you that technical and user information about boxes is rather scarce.

[birdman]

So simply believe us, when we say things need to be fixed in drivers. And the only one who can do that, is the manufacturer....who can't/won't do it unless the problem is reported to them!!!

[Rob van der Does]

We use to report issues to manufacturers once the issue is clear.

[Rob van der Does]

We use to report issues to manufacturers once the issue is clear.
But that's no guarantee for success :(

[birdman]

We use to report issues to manufacturers once the issue is clear.
So I could possibly help here, by finding out what the problem is (as I actually have the box to test on). Except that I can't find out what the FP should be doing, as no-one seems to able to say what that is - they only say that it behaves differently to what the code seems to expect.
Also, since the kernel is GPL'ed, and the module is distributed with the kernel, shouldn't the source code be available from the manufacturer somewhere?

[Leader]

OK. There is one problem I see.
The record icon still stops when it goes into Standby.

So if I get you right here. You want the record icon to display while in standby mode to show it is recording without pressing the power on button on the remote. so the record icon displays with the date and time.

[Leader]

When the Miracleboxes or shipped from the manufacturers they are shipped with the OpenMB image which the frontpanel works correctly. Changing the image to other image sources will always create problems,

Vix do a really good job here, but as you know the image is changed very offer because all the box manufacturers don't sing of the same hymn sheet.

There will always be some bug somewhere what don't run on some boxes thats the point of the updates to try and keep everyone happy, but not that easy when your trying to update 6 to 7 different manufacturers.

The very same problem with computer motherboard manufacturers and windows and linux software never can win unless they all work together which won't happen cause its all competition.

[birdman]

So if I get you right here. You want the record icon to display while in standby mode to show it is recording without pressing the power on button on the remote. so the record icon displays with the date and time.That's what I'd *like*, yes.
However - I can't find the code that sets the clock display on, and have this sneeking suspicion that it's in a totally different mode by then (as the network icon is switched off too - and that is being updated every 30s otherwise).

I hit another issue today - the record icon was on when manually starting up from Deep Standby. That was easy to fix - it can't be recoding anything at his point, so I just put a script at the end of rcS.d to echo 0 into symbol_circle.

[Leader]

Yes it will be in another pyo file as its a call from the remote to put the box into standby.

[birdman]

Yes it will be in another pyo file as its a call from the remote to put the box into standby.Time for me to start a thorough (:coffee:) browsing of the source code, then.
But your changes (whatever they were - I now have to find a Python decompiler...) have improved things - for me, at least.

[adm]

But your changes have improved things - for me, at least.

+1
It was one of the little things from the Toppy I missed :) A quick look at the front panel now tells me the box is on because it is recording.

[rossi2000]

save your time decompiling code, all the source code is available on github.

https://github.com/OpenViX/enigma2

[birdman]

save your time decompiling code, all the source code is available on github.

https://github.com/OpenViX/enigma2Except the code I want to see is the changes posted in post #2 to this thread.
I already have the git repositories downloaded.

[abu baniaz]

Search for
Easy Python Decompiler v1.2.7z

[birdman]

Search for
Easy Python Decompiler v1.2.7zExcept that seems to be a Windows-only build - which might not of much use to a Linux user like me....
I'll try
https://github.com/gstarnberger/uncompyle or
http://ltops9.wordpress.com/2014/04/17/decompyle-a-great-python-dissasemblerdecompiler/

[abu baniaz]

here you go.

[birdman]

Here is a patch against the Enigma2 v1001 (== Apollo.096 == current) version of RecordTimer.py that implements the changes which Leader made (slightly different - it uses try/except to simplify the assignment lists of the original).

This strikes me as doing the right thing in the right place, namely in getting the icon settings to be changed by the same code functions which actually start and stop recordings.
It's been working fine., although it does also need to have the symbol set to 0 at boot-up, as otherwise it remembers teh last state (whcih might not be "off"). That can be done with a /etc/rcS.d script or, ideally, enigma2 should ensure that when it start up.

Any chance of getting this included as part of the standard git code? (with the comments removed)
38977

(It's zip'ed, as the uploader seems to be unhappy with uploading a text file...)

[Leader]

Here is a patch against the Enigma2 v1001 (== Apollo.096 == current) version of RecordTimer.py that implements the changes which Leader made (slightly different - it uses try/except to simplify the assignment lists of the original).

This strikes me as doing the right thing in the right place, namely in getting the icon settings to be changed by the same code functions which actually start and stop recordings.
It's been working fine., although it does also need to have the symbol set to 0 at boot-up, as otherwise it remembers teh last state (whcih might not be "off"). That can be done with a /etc/rcS.d script or, ideally, enigma2 should ensure that when it start up.

Any chance of getting this included as part of the standard git code? (with the comments removed)
38977

(It's zip'ed, as the uploader seems to be unhappy with uploading a text file...)

Hi Birdman,
just looked at your patch and I tryed it that way when i wrote the code myself, but it wouldn't work h = int(f), cause on the f=open is looked as a complete file and not as a single character as I did myself think it would be looked at by the code the same as you are thinking here too, but when compiled and run it crashes out. That why I had to use all the if statements to get a integer. The code will just crash out if your patch is used.

[birdman]

Hi Birdman,
just looked at your patch and I tryed it that way when i wrote the code myself, but it wouldn't work h = int(f), cause on the f=open is looked as a complete file and not as a single character as I did myself think it would be looked at by the code the same as you are thinking here too, but when compiled and run it crashes out.It's working fine for me (I had two simultaneous recordings running tonight and so I looked for the icon changing when the first stopped, and it did what we expect).
And test scripts to see what happens if the file is empty, contains a non-numeric text, or contains multiple lines of text all work OK too. It just reads the first line, and if it isn't a number it ends up as 0.

I did apply this patch to the git source code, rather than the decompiled code of the *.pyo file. When I did the latter my Graphical EPG data disappeared (no, I don't understand that at all either...)