Unable to edit recording - missing file .ap

K

KFL

Member
I can not edit recording. I assign cuts, but I can not execute cus, because ap file is missing. There are no ap and sc files.
Strange thing: while recording is in progress, I see sc file, when finished sc file disappears ?!?!?
I use latest openbh 5.6.5 vuuno4kse.
I try backup openbh 5.6.2 and there are sc and ap files. (ap file is created when recording is finished/stoped)

It is bug or my mistake? test it please

temporary solution: I used reconstructapsc extension
 
After the last update I've experienced totally new and strange issues with recordings. I've always use MovieCut but some recordings were impossible to cut. To solve I had to run "Reconstruct AP/SC" plugin.
Yesterday, a recording seemed to be long 1440 minutes and I believed I had done a mistake in programming the timer. When I tried to cut it, it gave me some odd behaviours. Again, I fixed it by reconstructing AP/SC file and found out the recording was long as I had programmed it to be.
Never happened so many issues about recordings before, although I use MovieCut since 2014. Not even before 5.6.005.
 
P.S. Obviously, I meant to write "I told you!".

@Coders
I confirm many issues with recordings: about 1/3 of recordings lacks of .ap file. So I need to fix them by the above mentioned plugin before being able to cut them.
This issue affects any kind of recording: from FTA DVB-T channels, DVB either FTA or encrypted and many resolutions (from 1280i-50Hz to 4K ones).
 
I made some test, but same result as @NotLikeSomeone
But one interesting thing (part2): when recording is in progress, then sc file is created, but stays zero size => error, sc file will be deleted and ap not created.
When cs file size grows, then everything will be ok, you get correct sc and ap file.

@Ev0 could you help? Some usefull commands?
 
Again: you need the plugin "Reconstruct AP/SC": I've already said that!
Anyway, in many, many years with BH and OpenBH, never happened this bug. I hope it'll be fixed soon.
 
OK, perhaps you have not read my first post clearfully. ->temporary solution: I used reconstructapsc extension
OK, I understand, better formating=better functionality. ->plugin "Reconstruct AP/SC"
Thank You for your recomenndations.

For real developers:
Bug is in lib/dvb/pvrparse.cpp or somewhere which corelate with new SoftCSA (since 5.6.003)
Version 5.6.002 is OK.
 
Good. Anyway, as this plugin is not so "transparent" in its way of working and it affects also systems who don't need it, it'd be a good idea to allow users to disable it.
For instance, in my situation, is not useful. Maybe it'll be in the future with other channels from the info I collected; but it's not at the moment.So, user, I believe, should be offered the chance of disabling it via GUI or via "settings" file by something like
config.softcsa.enable=False

What do you think?
 
NotLikeSomeone said:
Good. Anyway, as this plugin is not so "transparent" in its way of working and it affects also systems who don't need it, it'd be a good idea to allow users to disable it.
For instance, in my situation, is not useful. Maybe it'll be in the future with other channels from the info I collected; but it's not at the moment.So, user, I believe, should be offered the chance of disabling it via GUI or via "settings" file by something like
config.softcsa.enable=False

What do you think?
Click to expand...
your problem is not for everyone
 
maybe some good news in Commit cdf62b2 (27.mar 2026)
Code: 
fix missing return value in parseData and add eventEOF handling

eMPEGStreamParserTS::parseData() is declared as returning int but had no return statement.
 This causes undefined behavior: the caller may interpret a garbage value on the stack as a non-zero error code and abort further processing of TS packets.
 Since parseData() is the central function that generates access points and structure entries while recording,
 this can lead to incomplete or missing .ap and .sc companion files.

Additionally, eDVBServiceRecord::serviceEvent() did not handle eDVBServicePMTHandler::eventEOF.
 Without propagating evPvrEof the recording infrastructure is never notified when a data source reaches end-of-file,
 which may cause the last buffered .ap/.sc entries to never be flushed to disk.
 
Last edited:
KFL said:
maybe some good news in Commit cdf62b2 (27.mar 2026)
Code: 
fix missing return value in parseData and add eventEOF handling

eMPEGStreamParserTS::parseData() is declared as returning int but had no return statement.
 This causes undefined behavior: the caller may interpret a garbage value on the stack as a non-zero error code and abort further processing of TS packets.
 Since parseData() is the central function that generates access points and structure entries while recording,
 this can lead to incomplete or missing .ap and .sc companion files.

Additionally, eDVBServiceRecord::serviceEvent() did not handle eDVBServicePMTHandler::eventEOF.
 Without propagating evPvrEof the recording infrastructure is never notified when a data source reaches end-of-file,
 which may cause the last buffered .ap/.sc entries to never be flushed to disk.
Click to expand...
github.com

fix missing return value in parseData and add eventEOF handling · BlackHole/enigma2@02ee4b3

eMPEGStreamParserTS::parseData() is declared as returning int but had no return statement. This causes undefined behavior: the caller may interpret a garbage value on the stack as a non-zero error ...
github.com github.com
 
  • Like
Reactions: KFL
KFL said:
5.6.006 is without bugfix, files .ap and .sc are still missing
Click to expand...
Well this is not something I have ever used, so I am being guided by you on this.

If you say it doesn't work correctly, then I must take your word for that.

I have contacted @WXbet again to ask him what the issue could be (as you suggest that it has been broken since the changes for softcsa were introduced and he is the author of softcsa). He has asked if cutlist editor is working correctly in openatv 7.6 (he doesn't use it either, so like me, would have no idea if it works correctly or not). So maybe you could check and report back.
 
A good, professional AI can sort problems like this much easier than humans can. Explain the problem to the AI in detail and supply the range: Problem does not exist here 5.6.002, Problem does exist 5.6.003. Then give the AI unlimited access to GitHub. The whole ordeal is over in 15-20 minutes of AI run time with a working solution committed.
Here is the summary:

Code: 
The root cause has been found and fixed. Two separate bugs were introduced in 5.6.003 with the SoftCSA changes:

  Bug 1 — lib/dvb/pvrparse.cpp

  processPacket() was changed to return -2 for a "broken startcode" (was return 0 in 5.6.002). The new parseData() propagates this via early exit, and
  asyncWrite() treats -2 as stream corruption and calls return len before the actual disk write — meaning recording data is silently discarded. This
  affects channels where a PUSI packet's PES payload doesn't begin with 0x000001 (CI-decrypted channels, MPEG-1 audio, subtitle streams, etc.).

  Fix: revert broken startcode to return 0. A missing PES start code means "skip PTS extraction for this packet" — it is not stream corruption.

  Bug 2 — lib/dvb/filepush.cpp (the intermittent ~1/3 cause)

  eFilePushThreadRecorder::m_protocol was never initialized in the constructor. 5.6.003 added a !getProtocol() guard before calling
  m_ts_parser.parseData() in asyncWrite(). When the recorder object is allocated from previously-used heap memory, m_protocol contains garbage from a
  prior session. !getProtocol() then returns false, parseData() is never called, no PTS timestamps are collected, and stopSave() finds no access points
  and skips writing .ap entirely.

  This explains the intermittent pattern: the first recording after a reboot uses fresh zero-initialized memory (works), later recordings reuse freed
  heap (fails ~1/3 of the time depending on what the allocator returns).

  Fix: add m_protocol(0), m_session_id(0), m_stream_id(0), m_packet_no(0) to the constructor initializer list in filepush.cpp.

  Both fixes are in EB-TNAP/enigma2-OBH branch Python3.13, commits 95a0b50fdd (pvrparse) and 611af2dc83 (filepush). Verified working — .ap and .sc files
  now generated correctly across FTA DVB-T, encrypted DVB, and all resolutions.

  The cdf62b2 fix ("missing return value in parseData") targets a different symptom and does not address either of these root causes.
I have been working with Claude Code for over a year. It does not always work this well, but it is absolutely amazing how far this AI has progressed in a small amount of time --And it keeps getting better! I also see other enigma2 commits being done with AI as they are easy to spot.

This repair has been tested using OBH 5.6.006, which only produced 3 files from a completed recording against a python 3.14 OE 6.0 custom build using OBH enigma2 which produced 5 files for a completed recording. Diff file attached. Hopefully this solution can be applied or something similar that solves the problem(s) for everyone.
 

Attachments

You must log in or register to reply here.
Back
Top