[VU+ Duo2] IPTV timers crash

[steven1977]

My timers keep crashing when trying the record IPTV. Free to air timers work fine as I watch these though the satellite feed. If I roll back to 5.1.030 all timers work fine. Anyone got any idea as to why it crashes

 

[pjhpjh79]

I'm getting the same issue.

 

[Andy_Hazza]

Will be to do with the different streamer type you have chosen for your IPTV maybe?


Sent from my iPhone using Tapatalk

 

[Andy_Hazza]

You may have downloaded a plugin that changes the default media player or something like that?


Sent from my iPhone using Tapatalk

 

[steven1977]

Nothings changed settings or plugin wise from 5.1.030 to 5.1.031. It does exactly the same on my sisters Duo2 and my dads solo2. I’ve re-flashed back to 5.1.030 and timers work fine. Might have to wait for 5.1.032 to be released and see if the issue goes away

 

[Andy_Hazza]

Nothing in the changelog to suggest anything has changed, so may likely still happen with 5.1.032.
Only other suggestion is do a clean install without any settings and plugins restore, so basically setting up as new and seeing if this helps.


Sent from my iPhone using Tapatalk

 

[abu baniaz]

If you still have the crash logs, please attach to thread. Default location is /home/root/logs.

Thanks.

 

[steven1977]

The log is empty. Sorry

 

[Andy_Hazza]

Enable them and repeat the action and it should create a crash log.


Sent from my iPhone using Tapatalk

 

[steven1977]

Just flashed 5.1.032 and it still does it. I've attached the crash log file

 

[Andy_Hazza]

View attachment 57153

Just flashed 5.1.032 and it still does it. I've attached the crash log file

Did you do a fresh install without any restores to test it?


Sent from my iPhone using Tapatalk

 

[twol]

Andy looks like a bug .......... will report it.

 

[birdman]

Andy looks like a bug .......... will report it.

The bug is in the code which logs the tuner being used.
There isn't a tuner, but for some reason it isn't coming back as None (it did when I tested it on an IP stream).

 

[birdman]

The fix is to change line 440 in RecordTimer.py from:

         tuner_info = tn is not None and chr(ord('A') + tn) or "?"

to:

         tuner_info = type(tn) is int and chr(ord('A') + tn) or "?"

I'll submit a PR.

EDIT:

 https://github.com/OpenViX/enigma2/pull/277

 

[Huevos]

The fix is to change line 440 in RecordTimer.py from:

         tuner_info = tn is not None and chr(ord('A') + tn) or "?"

to:

         tuner_info = type(tn) is int and chr(ord('A') + tn) or "?"

I'll submit a PR.

EDIT:

 https://github.com/OpenViX/enigma2/pull/277

This is just masking the problem. You really need to be looking at why the underlying code is not returning int or None.

fedata["tuner_number"] should only ever contain an int, or not exist. So what does it contain that it should not? And where/how is that being populated.

 

[birdman]

fedata["tuner_number"] should only ever contain an int, or not exist.

The code change means that it will only ever be used when it contains an int - this makes the code more robust should anyone change what it does contain.
I'm interested in fixing the current problem now. Looking at the underyling oddity can then be done at leisure by someone who can reproduce it (I can't, as when I added the original logging I did test it with an IP stream in as far as I could set on up, but it didn't show this issue).

 

[Huevos]

Looking at the underyling oddity can then be done at leisure by someone who can reproduce it (I can't, as when I added the original logging I did test it with an IP stream in as far as I could set on up, but it didn't show this issue).

That is not how it works. Before any changes are made for bugs there has to be a recipe to reproduce the bug and the bug has to be confirmed by a team member. And then a proper fix, not a fix to hide the problem so it pops up elsewhere.

This is exactly why enigma code is in such a mess.

 

[birdman]

That is not how it works. Before any changes are made for bugs there has to be a recipe to reproduce the bug and the bug has to be confirmed by a team member.

So you're happy to ignore the fact that there is a debug log reporting the error?
In much the same way as you will ignore code changes that makes some tuners usable just because you don't have one?

And then a proper fix, not a fix to hide the problem so it pops up elsewhere.

As I've noted, the code change is to more robust code. We are about to use an item as an int, so check that it is one before doing so.

 

[ccs]

That is not how it works. Before any changes are made for bugs there has to be a recipe to reproduce the bug and the bug has to be confirmed by a team member. And then a proper fix, not a fix to hide the problem so it pops up elsewhere.

This is exactly why enigma code is in such a mess.

Surely in this case, if the problem pops up elsewhere, it is nothing to do with the original change to add tuner details?

There must be loads of errors in the enigma code which can be spotted but not (easily) reproduced ?

 

[twol]

The code change means that it will only ever be used when it contains an int - this makes the code more robust should anyone change what it does contain.
I'm interested in fixing the current problem now. Looking at the underyling oddity can then be done at leisure by someone who can reproduce it (I can't, as when I added the original logging I did test it with an IP stream in as far as I could set on up, but it didn't show this issue).

@Birdman @ Huevos
I kind of understand both your views but normally I would expect Birdman to provide some code to those that can reproduce it, to display what is in the field - and then maybe we can find why it is being corrupted and by what..... just a suggestion