View Full Version : [VU+ Zero4K] Recording crashes in 6.2.008
Happens every time. Box has pvr kit installed (if it makes difference)
Crashlog attached, but relevant part:
< 153.5243> 16:33:54.1352 Traceback (most recent call last):
< 153.5243> 16:33:54.1353 File "/usr/lib/enigma2/python/Screens/InfoBarGenerics.py", line 280, in actionA
< 153.5253> 16:33:54.1363 File "/usr/lib/enigma2/python/Tools/RedirectOutput.py", line 16, in write
< 153.5258> 16:33:54.1367 TypeError: in method 'ePythonOutput', argument 1 of type 'char const *'
Additional information:
Wrong number or type of arguments for overloaded function 'ePythonOutput'.
Possible C/C++ prototypes are:
ePythonOutput(char const *,int)
ePythonOutput(char const *)
< 153.5258> 16:33:54.1368
< 153.5260> 16:33:54.1370 [ePyObject] (CallObject(<bound method InfoBarUnhandledKey.actionA of <class 'Screens.InfoBar.InfoBar'>>,(352, 1)) failed)
So what did you press that caused the crash?
Just red record button and then OK button. Crash happens always, no matter what channel.
I have many E2 boxes, only my Zero 4K has this issue.
I'll add some more information. I tried flashing 6.2.008 again and restored settings. Same issue. (Not tested without settings restore)
HDD seems fine, plenty of free space. I can play previous recordings, but can't start new. (It actually starts writing to disk, but box crashes)
Tested Uno 4K, works fine, it has USB HDD. Only Zero 4K has internal HDD, not sure what else could be different?!
I've used this box previously without any issues. Problem started after updating openvix
Can you try without settings restore please. Just basic setup. No extra plugins.
I should have looked my self where it crashes. RedirectOutput.py seems to be just for logging.
Added try, except, pass to line 16 and recording working fine now.
Maybe turning off debug logs would have also helped.
Anyway issue solved for me now, but there is still bug in code
Here traceback from debuglog, if someone wants to take a look. Would be interesting to know what self.line, self.level contains when it crashes.
< 4037.8571> 17:38:38.4681 Traceback (most recent call last):
< 4037.8572> 17:38:38.4681 File "/usr/lib/enigma2/python/StartEnigma.py", line 224, in processDelay
< 4037.8581> 17:38:38.4690 callback(*retval)
< 4037.8581> 17:38:38.4691 File "/usr/lib/enigma2/python/Screens/InfoBarGenerics.py", line 3333, in recordQuestionCallback
< 4037.8585> 17:38:38.4694 File "/usr/lib/enigma2/python/Screens/InfoBarGenerics.py", line 3253, in startInstantRecording
< 4037.8588> 17:38:38.4697 File "/usr/lib/enigma2/python/RecordTimer.py", line 1275, in record
< 4037.8591> 17:38:38.4701 File "/usr/lib/enigma2/python/timer.py", line 229, in addTimerEntry
< 4037.8594> 17:38:38.4704 File "/usr/lib/enigma2/python/timer.py", line 268, in calcNextActivation
< 4037.8597> 17:38:38.4706 File "/usr/lib/enigma2/python/timer.py", line 363, in processActivation
< 4037.8601> 17:38:38.4710 File "/usr/lib/enigma2/python/RecordTimer.py", line 1009, in doActivate
< 4037.8607> 17:38:38.4717 File "/usr/lib/enigma2/python/RecordTimer.py", line 676, in activate
< 4037.8611> 17:38:38.4720 File "/usr/lib/enigma2/python/RecordTimer.py", line 485, in log_tuner
< 4037.8614> 17:38:38.4723 File "/usr/lib/enigma2/python/RecordTimer.py", line 284, in log
< 4037.8617> 17:38:38.4726 File "/usr/lib/enigma2/python/Tools/RedirectOutput.py", line 16, in write
< 4037.8620> 17:38:38.4729 TypeError: in method 'ePythonOutput', argument 1 of type 'char const *
Here traceback from debuglog, if someone wants to take a look. Would be interesting to know what self.line, self.level contains when it crashes.
< 4037.8571> 17:38:38.4681 Traceback (most recent call last):
< 4037.8572> 17:38:38.4681 File "/usr/lib/enigma2/python/StartEnigma.py", line 224, in processDelay
< 4037.8581> 17:38:38.4690 callback(*retval)
< 4037.8581> 17:38:38.4691 File "/usr/lib/enigma2/python/Screens/InfoBarGenerics.py", line 3333, in recordQuestionCallback
< 4037.8585> 17:38:38.4694 File "/usr/lib/enigma2/python/Screens/InfoBarGenerics.py", line 3253, in startInstantRecording
< 4037.8588> 17:38:38.4697 File "/usr/lib/enigma2/python/RecordTimer.py", line 1275, in record
< 4037.8591> 17:38:38.4701 File "/usr/lib/enigma2/python/timer.py", line 229, in addTimerEntry
< 4037.8594> 17:38:38.4704 File "/usr/lib/enigma2/python/timer.py", line 268, in calcNextActivation
< 4037.8597> 17:38:38.4706 File "/usr/lib/enigma2/python/timer.py", line 363, in processActivation
< 4037.8601> 17:38:38.4710 File "/usr/lib/enigma2/python/RecordTimer.py", line 1009, in doActivate
< 4037.8607> 17:38:38.4717 File "/usr/lib/enigma2/python/RecordTimer.py", line 676, in activate
< 4037.8611> 17:38:38.4720 File "/usr/lib/enigma2/python/RecordTimer.py", line 485, in log_tuner
< 4037.8614> 17:38:38.4723 File "/usr/lib/enigma2/python/RecordTimer.py", line 284, in log
< 4037.8617> 17:38:38.4726 File "/usr/lib/enigma2/python/Tools/RedirectOutput.py", line 16, in write
< 4037.8620> 17:38:38.4729 TypeError: in method 'ePythonOutput', argument 1 of type 'char const *
......... deleted
Found cause and is reported earlier.
When new recording starts, it seems to also clean trash in the background.
Trashcan.py line 195: print("[Trashcan] Failed to stat %s:" % name, e)
"name" comes directly from filesystem and not guaranteed to be utf-8 only.
There it goes to RedirecOutput.py and ePythonOutput() is not protected against non utf-8 in str.
Problem was filename with special character in trash. I'm sure Python27 did not have these issues..
Found cause and is reported earlier.
When new recording starts, it seems to also clean trash in the background.
Trashcan.py line 195: print("[Trashcan] Failed to stat %s:" % name, e)
"name" comes directly from filesystem and not guaranteed to be utf-8 only.
There it goes to RedirecOutput.py and ePythonOutput() is not protected against non utf-8 in str.
Problem was filename with special character in trash. I'm sure Python27 did not have these issues..
The crash in RedirectOutput is caused by the log entry created in Recordtimer. .. which is why I asked for teh debug using the attachment.
would you do that so that I can see what is generated?
The zero4k is a special as its sold as a zapper … only, although people apply the change to allow recording'
Found cause and is reported earlier.Where was it reported earlier?
There it goes to RedirecOutput.py and ePythonOutput() is not protected against non utf-8 in str.But RedirectOutput is checking for being sent bytes. If it is sent a str then it should already be OK.
Problem was filename with special character in trash. I'm sure Python27 did not have these issues..Py2 only had strings of bytes. Py3 has byte strings and Unicode strings. Mixing them has been a cause of many issues.
Where was it reported earlier?
I mean it was reported earlier that ext4 is not limited to utf-8. All code must be reviewed where filename is used. Same if you for example insert NTFS usb stick from Windows. Filenames are not utf-8.
But RedirectOutput is checking for being sent bytes. If it is sent a str then it should already be OK.
No, type was str when it came there (not bytes). str contained python3 surrogate.
I know this, because I checked what self.line contained when it crashed. (Because I was interrested)
I mean it was reported earlier that ext4 is not limited to utf-8. All code must be reviewed where filename is used. Same if you for example insert NTFS usb stick from Windows. Filenames are not utf-8.
No, type was str when it came there (not bytes). str contained python3 surrogate.
I know this, because I checked what self.line contained when it crashed. (Because I was interrested)
Could you just do me a favour and use the attachment in post #8 - I would like to try and fix this rather than your bypass (try/except)
Could you just do me a favour and use the attachment in post #8 - I would like to try and fix this rather than your bypass (try/except)
I have access to this box again next weekend. And I already cleaned trash.
But it's clear what the problem was. Non utf-8 character in filename.
If you want to fix crash in RedirectOutput, just make sure there are no surrogates when passing str to ePythonOutput(). (Surrogate means non utf-8 characters escaped inside str)
There was also exception in trashcan. Code needs to be checked for non utf-8 filenames starting from:
line 180: for root, dirs, files in os.walk(trashfolder, topdown=False):
Is that "trashfolder" str or bytes here? It affects what "files" contains after.
Further testing, create non utf-8 filenames to hdd/media and start testing..
I have access to this box again next weekend. And I already cleaned trash.
But it's clear what the problem was. Non utf-8 character in filename.
If you want to fix crash in RedirectOutput, just make sure there are no surrogates when passing str to ePythonOutput(). (Surrogate means non utf-8 characters escaped inside str)
There was also exception in trashcan. Code needs to be checked for non utf-8 filenames starting from:
line 180: for root, dirs, files in os.walk(trashfolder, topdown=False):
Is that "trashfolder" str or bytes here? It affects what "files" contains after.
Further testing, create non utf-8 filenames to hdd/media and start testing..
The crash log you supplied does not show that as the problem. The bad characters are coming from RecordTimer.py and should be fixed at source, not in RedirectOutput.py.
The crash log you supplied does not show that as the problem. The bad characters are coming from RecordTimer.py and should be fixed at source, not in RedirectOutput.py.Might need it in both.
You don't have total control over what is on the file-system in general, so need to be able to cater for reporting anything.
The crash log you supplied does not show that as the problem. The bad characters are coming from RecordTimer.py and should be fixed at source, not in RedirectOutput.py.
If it makes more sense, here what I did to RedirectOutput.py
try:
ePythonOutput(self.line, self.level)
except:
s = ''
for i in self.line:
s = s + str(ord(i)) + ' '
ePythonOutput(s, self.level)
ePythonOutput(self.line, self.level) # Let is crash
After receiving and converting that debug back to string:
[Trashcan] Failed to stat t\udce4htisade.ts: in method 'eBackgroundFileEraser_erase', argument 2 of type 'std::string const &'\n
This is "self.line" that caused crash. That original exception was inside try/except.
@twol thanks for the fix, but I don't think simply ignoring characters is the correct way. It fixes the crash, but does not erase the file.
Question now is why file_eraser.cpp does not accept bytes in python3, if it was bytes in python2?
Can it be modified to take also bytes, I think that would be the correct fix.
It would also make sense to add try/except to RedirectOutput (including some debug output to except block if it happens)
Logging should never crash and there are other places in code where same could happen.
Can you get the exception from the debug log so we can analyse the problem.
Can you get the exception from the debug log so we can analyse the problem.
Exception in Trashcan or RedirectOutput?
Both are caused by '\udce4' in str.
I tried fixing enigma.eBackgroundFileEraser.getInstance().erase(f n) using bytes, but exception "argument 2 of type 'std::string const &"
Does anyone know reason why, since it was bytes in python2? Any other way to make bytes work here? Only other option is to fix '\udce4' issues in C
@twol thanks for the fix, but I don't think simply ignoring characters is the correct way. It fixes the crash, but does not erase the file.
Question now is why file_eraser.cpp does not accept bytes in python3, if it was bytes in python2?
Can it be modified to take also bytes, I think that would be the correct fix.
It would also make sense to add try/except to RedirectOutput (including some debug output to except block if it happens)
Logging should never crash and there are other places in code where same could happen.
" It fixes the crash, but does not erase the file." - I know I am still looking at it!! Just wanted the crash removed.
The issue with your file names is that in python3 we have to use an encoding that will handle the conversion to Unicode string .... and we are guessing ... the "standard" is utf-8 (suits English speaking countries because that's the same as Ascii more or less), but doesn't handle your file names
"Question now is why file_eraser.cpp does not accept bytes in python3, if it was bytes in python2?" - it accepts a string (of bytes) which can be Ascii(py2) or Unicode (py3). Python 2 will actually handle both (ascii and Unicode if used ) transparently.
In py3 you can have either a unicode string or bytes that can be handled by core & I/O routines, where a Unicode byte can be encoded into 1-> 4 bytes in a byte string, depending on the encoding (and visa versa).
Of course, the python3 developers tell you not to touch any byte string unless you know the encoding, which is kind of nice in theory but in our case rubbish, as our inputs come at us from all over --- including helpful Windows file names.
You need to read up on py2 vs py3 - its not that simple. If it was we wouldn't have these and many other issues.... espedcially coming from an initial python2 base where we initially supported both python versions.
I agree on both your last 2 points, but we also need to be able to identify and fix the initial issue.
Exception in Trashcan or RedirectOutput?
Both are caused by '\udce4' in str.
I tried fixing enigma.eBackgroundFileEraser.getInstance().erase(f n) using bytes, but exception "argument 2 of type 'std::string const &"
Does anyone know reason why, since it was bytes in python2? Any other way to make bytes work here? Only other option is to fix '\udce4' issues in C
I guess you are pushing a unicode string to FileEraser not bytes.
No - we have to learn how to resolve the unicode string byte ( \udce4 )and others in python
Does anyone know reason why, since it was bytes in python2?Python2 did not have bytes.
Python 2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:25:05) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> b'abc'
'abc'
>>> type(b'abc')
<type 'str'>
>>>
Python 3.10.4 (tags/v3.10.4:9d38120, Mar 23 2022, 23:13:41) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> b'abc'
b'abc'
>>> type(b'abc')
<class 'bytes'>
>>>
The issue with your file names is that in python3 we have to use an encoding that will handle the conversion to Unicode string ....No, we don't . A filename (and pathname) should be kept as bytes. If it is created from a Unicode string it should be decoded to bytes.
Of course, the python3 developers tell you not to touch any byte string unless you know the encoding, which is kind of nice in theory but in our case rubbish, as our inputs come at us from all over --- including helpful Windows file names.Indeed, they have no encoding at all. They are just a collection of bytes. You can name a file anything with any combination of bytes you wish, in any order (except '/' and '\0'). Hence they should always be kept as bytes and passed on as such.
No, we don't . A filename (and pathname) should be kept as bytes. If it is created from a Unicode string it should be decoded to bytes.
Indeed, they have no encoding at all. They are just a collection of bytes. You can name a file anything with any combination of bytes you wish, in any order (except '/' and '\0'). Hence they should always be kept as bytes and passed on as such.
“ If it is created from a Unicode string it should be decoded to bytes.“ ………. how do you (en)code it?
„ You can name a file anything with any combination of bytes you wish, in any order“ - and how is an application supposed to know what those bytes represent?
They are just a collection of bytes. You can name a file anything with any combination of bytes you wish.And that collection of bytes was created from a charset. And also if we want to send a "collection of bytes" to the GUI we need to know the charset they were saved from so we can display them correctly.
“ If it is created from a Unicode string it should be decoded to bytes.“ ………. how do you (en)code it?
[gmllaptop]: python3
Python 3.10.4 (main, Jun 29 2022, 12:14:53) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> str = "déjà"
>>> bytes = str.encode()
>>> print(bytes)
b'd\xc3\xa9j\xc3\xa0'
„ You can name a file anything with any combination of bytes you wish, in any order“ - and how is an application supposed to know what those bytes represent?They represent a filename (or rather "an entry in the file-system"). That is all.
And that collection of bytes was created from a charset. And also if we want to send a "collection of bytes" to the GUI we need to know the charset they were saved from so we can display them correctly.Which is nothing to do with the file-system.
The relevant thing is that the filename has to be kept as bytes. If you wish to display this that is another matter, but you then only convert it for display - you have to retain the original bytes for actual file-system activity.
Which is nothing to do with the file-system.
The relevant thing is that the filename has to be kept as bytes. If you wish to display this that is another matter, but you then only convert it for display - you have to retain the original bytes for actual file-system activity.
You're welcome to provide a working solution. :)
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.