39 replies to this topic

[WanWizard]

I've asked again, Erik isn't online much due to health reasons.

[Qu@rk]

Thanks. I am sorry to hear that, I hope Erik is well soon. That's more important than this problem.

 

Please let me know if you or Erik needs support. But my crashlog (first post) should show everything needed, I hope. 

[Erik Slagter]

I have done quite some work on this source file in the last year, but not in the section the error comes from. It might be related in some way though.

 

I still have the plan to revert all my changes to the file, because the code I added triggers a very ugly bug in glibc, especially on MIPS (less on ARM), but the code is needed for Broadcom transcoding integration. So I will revert all the change and create a filepush class especially for transcoding. That sounds logical and easy as well, but it's quite complex to integrate it into enigma as at various points enigma expects a "filepush" class and not a "transcoding_filepush_class_invented_by_me".

 

It would help if someone could reproduce the issue and actually print the values of both reported variables.

[ims]

@Erik Slagter - here are two created 'problematic' .cuts files

 

 

How is possible in most cases simulate on H7 wrong .cuts file: 

- remove .cuts file

- open movie in CutListEditor

- skip to some time, use STOP for pause movie, then severals use "left/right" and set "remove before this position".

- exit editor

- open same movie again in CutListEditor ... it should crash, if not, try again similar steps

 

but on vs1500 is impossible for me create wrong .cuts file (but edit movie with 'corrupted' .cuts from H7 crash on vs1500 too)

 

Attached Files

•  cuts.zip   323bytes   2 downloads

[Dimitrij]

CutListEditor: Improvements

[WanWizard]

Are they relevant? The first one looks cosmetic.

[ims]

I put before 'ASSERTION' in filepush.cpp debug message:

eDebug("[* * * eFilePushThread * * *] current_span_remaining: %d m_blocksize: %d", current_span_remaining, m_blocksize);  

And with problematic cuts file I got:

[* * * eFilePushThread * * *] current_span_remaining: 195484520 m_blocksize: 188
[eDVBServicePlay] have 1 video stream(s)../../git/lib/dvb/filepush.cpp:72 ASSERTION !(current_span_remaining % m_blocksize) FAILED!

Edited by ims, 2 January 2022 - 13:26.

[ims]

It seems, it could solve this problem

[nautilus7]

Hi, that PR is for the python3 branch... Nothing to do with the issue reported here.

Edited by nautilus7, 23 January 2022 - 03:52.

[ims]

I know, that it is pr for python3, but for python2 there should be same for writing cutlist to binary .cuts, imho. I tried it and it seems, crashing dissappeared for me now.

[Dimitrij]

ims

Maybe need apply this https://github.com/O...5ceb4e6f9a04594

Edited by Dimitrij, 23 January 2022 - 10:29.

[ims]

Writing cutlist as binary it solve, imho ... 

No crash more....

 

I tried write cutlist twice to 2 files with "old" code (1,2) and you can see differences in size on attached screenshot in .cuts and .cuts1, cuts2.

 

PR is here

Attached Files

•  bin.PNG   22.48KB   0 downloads

Edited by ims, 23 January 2022 - 11:18.

[Dimitrij]

Great news.

[nautilus7]

@ims I doubt your PR will change anything on this matter. Apart that python 2 works with bytes by default, the crash described here is possibly related to the cpp code.

[ims]

agree ... but weird, that used "reset" on movie write same cutlist with different size...

Edited by ims, 23 January 2022 - 13:26.

[WanWizard]

In which case it is not much use to merge the PR?

[ims]

In which case it is not much use to merge the PR?

pr closed

[WanWizard]

The filepump requires fixed records, 188 bytes long, and expects remaining size to be an exact multiple of 188.

 

I'm looking in the cutlisteditor code, but nowhere is there a check on this size, whatever is the current position seems to be saved.

As the assert() in the filepump suggests the record size is a prerequisite for processing, I'd say the cutlisteditor has to make sure the data written in the cuelist should reflect that, but if I look at the code, all mark points are in time, not in bytes.

 

Which means dvb.cpp returns a non-aligned value somewhere, after seeking through the recording for a mark point in time.

[WanWizard]

Bug found, fixed, and backported to 8.3-release.

[Qu@rk]

Thank you. Merry Christmas and happy holidays!