Forums

With RC9.0, Windows filenames that contain special characters, like umlauts, cause green screen.

For example, if you try to view an image named München.jpg from a USB storage, PicturePlayer will crash.
Similar, when trying to play media files with this kind of filenames.

It seems, there is filename decoding problem...

PS. Release 8.3 is not affected.

Thanks for reporting, it is looked into.

Any news on this matter?

I don't see any problem. Picture player displays it just fine.

Isn't your problem that you read or copy the files from a Windows system without proper characterset conversion?

Well, that is new to me. I wasn't aware that when using PLi9 I had to make a "proper characterset conversion".

And how would I do that?

I'm not says that IS the problem, I'm saying that COULD BE the problem.

And it is nothing new. Windows uses the ISO-8859-1 characterset (at least in the Latin part of the world), Linux (and most of the rest of the world) uses UTF-8. Which means that if you have non-ASCII text (in files, or file names), it needs to be converted.

When you look at the USB via the movie list or the picture player, does the name of the file show up properly? Like so, or different? What filesystem is used on the USB disk? What is the source of the image, a Windows PC?

The source of the file is a Windows10 PC with german locale.

The USB flash drive used is FAT32.

Both Media Player and Picture Player crash immediatly if they encounter this kind of file names.

There is no way of telling how the file names would have been shown.

I have attached a file for testing.

As mentioned in the opening post, PLi8.3 does not suffer from this problem.

 Munich.zip   16.34KB   8 downloads

That is known but not very helpful.

OpenPLi 8 and older use python2, which doesn't know or care about charactersets, everything is a sequence of bytes, and it happily displays crap if the source is not UTF-8.

OpenPLI 9 and newer use pyhon3, which does differenciate between bytes and string, and you need to know the encoding to be able to convert bytes to string and display. This crashes if the data is in a non-supported characterset.

If so, we need the logs of the crashes so we can see if something can be done about it.

Is the sample file not sufficient for the PLi developers to reproduce the crash and look into the logfiles?

The less work you do, the more we have to do, the longer it takes before something will pick it up. If at all...

The file in your zip doesn't crash here (even though the filename is mangled), so the ball is in your court again...

It is now six weeks since I have reported this issue. Meanwhile I am back to 8.3.

Will provide logfiles tomorrow.

Report an issue = post a crash log. And not moan about it for 6 weeks without providing any lead.

And even when you eventually post the alleged offending image, your issue can't be reproduced, it displays fine here.

see post #2

Attached a crash.log and and sample file for testing (this time compressed with tar)

 enigma2_crash_munich.log   17.24KB   7 downloads

 munich.tar.gz   16.23KB   5 downloads

To reproduce the crash, copy the sample file (munich.tar.gz) to the box to folder tmp and decompress it.

Then start the Picture player and select the tmp folder.

I don’t see any problems on my home assembly-develop branch. There are no errors on Vu+ and Hisi.

05:33:16.5584 [Skin] Processing screen 'Pic_Full_View', position=(0, 0), size=(1920x1080) for module 'Pic_Full_View'.
05:33:16.5622 [ePicLoad] setPara max-X=1920 max-Y=1080 aspect_ratio=1.000000 cache=0 resize=1 bg=#00000000
05:33:16.5630 [ePicLoad] decode picture... /tmp/M?nchen.png
05:33:16.5639 [Skin] Parsing embedded skin '<embedded-in-SimpleSummary>'.
05:33:16.5664 [Skin] Processing screen '<embedded-in-SimpleSummary>' from list 'Pic_Full_View_summary, SimpleSummary', position=(0, 0), size=(132x64) for module 'SimpleSummary'.
05:33:16.5692 [Screen] Showing screen '['Pic_Full_View_summary', 'SimpleSummary']'.
05:33:16.5714 [Screen] Showing screen 'Pic_Full_View'.
05:33:16.5727 [InfoBarGenerics] Key: 352 (Break) KeyID='KEY_OK'.
05:33:16.5748 "::ffff:192.168.50.163" - - [11/Oct/2023:02:33:15 +0000] "GET /api/remotecontrol?command=352&_=1696991586708 HTTP/1.1" 200 84 "http://192.168.50.113/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36"
05:33:16.6811 [gAccel] accel alloc failed

05:33:16.6811 [gSurface] ERROR: accelAlloc failed
05:33:16.7112 [ePicLoad] decode picture... /tmp/M?nchen.png
05:33:16.8253 [gAccel] accel alloc failed

05:33:16.8254 [gSurface] ERROR: accelAlloc failed
05:33:17.5897 [eConsoleAppContainer] user kill(SIGKILL)
05:33:17.5951 [eConsoleAppContainer] Starting /usr/bin/grab
05:33:17.6014 "::ffff:192.168.50.163" - - [11/Oct/2023:02:33:16 +0000] "GET /api/pipinfo?_=1696991586709 HTTP/1.1" 200 33 "http://192.168.50.113/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36"

Thank you foxbob. Could you test it also with an unmodified PLi develop image and english language?

I did that, same experience as foxbob.

The crash log shows

PC: b60f7194
Fault Address: 00000000
Error Code: 0
Backtrace:
/usr/bin/enigma2(_Z17handleFatalSignaliP9siginfo_tPv) [0x7780C]
/lib/libc.so.6(__default_rt_sa_restorer) [0xB60F8000]
/lib/libc.so.6(gsignal) [0xB60F7194]
/lib/libc.so.6(abort) [0xB60E3FA0]
/usr/lib/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv) [0xB63672D0]
/usr/lib/libstdc++.so.6(n/a) [0xB6365298]
-------FATAL SIGNAL 6

which is a crash in the C code, without any trace that could lead us to the root cause of the problem. It might be specific to the HD51, or the SoC Platform.

I'll try later on a VU+, which is also a Broadcom Arm box.

I have now tested on another box, the Xtrend ET7500. It crashes too.

If it was related to the SOC it would crash also with Rel.8.3.

I suspect, the issue is how python3 passes the filename to the C code.

I wonder why the filename is shown differently in the tests performed by WanWizard and foxbob.

Does it depend on locale settings?