Unable to edit recording - missing file .ap

NotLikeSomeone said:
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).
Click to expand...
Hello, I have already asked @KFL.

Maybe you can also give me more information.
Is this a box related issue or channel related issue?

I'm currently not able to reproduce this on any DVB-S (Astra 19'2) service.

All my recordings have ap and sc files.
 
Please can one of you that reported the issue reply to @jbleyel's question.

He would like to know how to replicate the original issue, so that he can double check the same problem does not exist in OpenATV image.
 
Please read my first post first.
How I found problem:
-open recordings
-move to recording
-press menu
-I open cutlist editor
-set marks (cut before and cut after)
-exit cutlist editor
-press menu
-I open Execute cuts
-Error: missing ap file, can not cut file
Investigation:
-telnet/ssh to box
-cd /hdd/movies
-ls -lt | head -n20 (list newest 20 files )
-recording conatins 5 files: name.ts, name.eit, name.ts.meta, name.ts.cuts, name.ts.sc, name.ts.ap
-missing files name.ts.ap and name.ts.sc
Testing (see my first post):
-start recoding via remote
-telnet/ssh to box
-cd /hdd/movies
-ls -lt | head (list newest 10 files, repeat this more times)
-focus on sc and ap
-I see name.ts.sc while recording is in progress
-I do not see name.ts.ap file (it is correct, file will be created after recording is finished)
-stop recording via remote
-ls -lt | head (list newest 10 files )
-focus on sc and ap
-I do not see name.ts.sc (deleted)
-I do not see name.ts.ap (not created)
-it does not matter if service was crypted or FTA
Testing backup:
-restore 5.6.002
-same steps
-there is no problem
Testing 5.6.005+
-fresh install
-same steps
-ap and sc files missing
-result: it is not problem with my setting
Final result: see my first post
I have asked AI about that which points me to dvrparser.cpp, but I am not developer.
I am only familiar with terminal (putty/kitty/other) and linux systems.
 
Yes. You don't understand.
I need a how to reproduce the bug where ap and sc files are missing after recording with the older BH version where the bug is not fixed.
What channel(s) cause the issue and what Box.

I can't reproduce with VU+ Solo4K and any Astra 19,2 channel.
 
jbleyel said:
Yes. You don't understand.
I need a how to reproduce the bug where ap and sc files are missing after recording with the older BH version where the bug is not fixed.
What channel(s) cause the issue and what Box.

I can't reproduce with VU+ Solo4K and any Astra 19,2 channel.
Click to expand...
The problem was in enigma2 source files and has been fixed.
The problem existed in online updates and was removed in online updates. This means for you to "see" the problem, you would either need an image that originally had the problem or custom build the image from sources that had the problem in it.

Go back and carefully read the first page of this thread. If you do not have a backup image or a non-updated image where the problem exists, then you would need to build a custom image and include the script that introduced the problem. Do you understand this?
 
I’m the developer of this particular part of the code.
And the last change is not a fix it’s only a workaround.

So again. I need to reproduce the issue to make a real fix.
 
I think the whole enigma source code could considered to be a workaround, Don't you?
Why may I ask did you change the 0 to -2 to begin with? NONE of the OE Alliance enigma2 distros are the same. And why can't you build without the workaround commit and see the problem? Very good detailed information is in page 1 of this thread. It explains exactly how to see the problem. I am located in North America, so I doubt you can receive the satellite or channels that I tested with. They need to be bona-fide FTA channels that you are recording to see the problem. If I could, I would reproduce the problem in front of you, but I cannot do that unless you want to pay Atlanta a visit.
 
KFL said:
@jbleyel
You don't read our posts carefully.
I think you're a bot or troll, sorry.
I'm leaving this discussion, it's a waste of time. It's already fixed.
Click to expand...
I already said above, he's a dev from OpenATV team.

So he has reasons for asking what the issue is (or was) and how to reproduce it.
 
In a way, to me, this is like looking at three separate bowls of spaghetti.

The OpenATV enigma2's (2) are different from the OpenVix enigma2's (2) by a considerably amount. The One OBH enigma2 is closest to OpenVix release, but still there are around 300 different files or scripts in OBH enigma2 as compared to OpenVix enigma2 (Release).

This particular problem never existed in either OpenATV or OpenVix that I could find or reproduce, and the problem in OBH was only seen after an edit that did not bother OpenATV or OpenVix. So since what was reverted was a work-around, I would really like to see the proper or real solution and maybe learn a trick or two from it. There are great people that work on and maintain these distros, and I respect that. But I cannot provide any useful test channels due to being located in the United States.

One way to solve this might be to revert the work-around commit that solved it. Then maybe everyone that is interested could then see it again? This is my best suggestion at this point. The problem does not exist on all channels...
 
el bandido said:
In a way, to me, this is like looking at three separate bowls of spaghetti.

The OpenATV enigma2's (2) are different from the OpenVix enigma2's (2) by a considerably amount. The One OBH enigma2 is closest to OpenVix release, but still there are around 300 different files or scripts in OBH enigma2 as compared to OpenVix enigma2 (Release).

This particular problem never existed in either OpenATV or OpenVix that I could find or reproduce, and the problem in OBH was only seen after an edit that did not bother OpenATV or OpenVix. So since what was reverted was a work-around, I would really like to see the proper or real solution and maybe learn a trick or two from it. There are great people that work on and maintain these distros, and I respect that. But I cannot provide any useful test channels due to being located in the United States.

One way to solve this might be to revert the work-around commit that solved it. Then maybe everyone that is interested could then see it again? This is my best suggestion at this point. The problem does not exist on all channels...
Click to expand...
OpenVix would have had the issue, as they took your fix.

However I am not sure there was a public image released that had the issue included.
 
Correct. OpenVix has it in Developer and not in Release. The only way to see it is to build it.

I will double check later today by installing a OpenVix release image. I am almost certain it does not have the missing files issue, and it also will not have the "fix". I remember doing this very thing earlier this month and wondering Why Vix does not have the problem and OBH does.
 
Apparently OpenVix did not or does not need the "fix".

Here is a recording done with OpenVix 6.8.003 (Release):
OpenVix-6,8.003-2026-04-25 12-10-35.png

All recording files present.

Look at the Release OpenVix-on left as Compared to current OBH-on right:
Vix_on_left-obh_on-right-2026-04-25 12-24-15.png

Vix_on_left-obh_on-right1 2026-04-25 12-25-30.png
To look at OBH again will take an image build. I will try to do that this evening. From what I see, OpenVix took a commit they do not need. Let's see if we can rebuild OBH with the problem so it can again be seen...
 
Thanks.

So it seams that Astra 19.2 channels do not have that issue and there must be a difference between OBH, Vix and ATV.

I’m pretty sure the difference is in the tuner code.

I can provide you a patch for testing because I’m not able to build an OBH image.

Or I send @Ev0 the patched files an he can make a special enigma.ipk for testing.
 
Ev0 said:
OpenVix would have had the issue, as they took your fix.

However I am not sure there was a public image released that had the issue included.
Click to expand...
What was done to fix this is at minimum, mostly correct. I do not see what the fuss is about. So let's go through it one time and be done with it!
The suggested commit to fix the missing recording files was only this:
C++: 
diff -urpN a/filepush.cpp b/filepush.cpp
--- a/filepush.cpp    2026-04-11 20:33:44.467082000 -0400
+++ b/filepush.cpp    2026-04-11 19:41:49.914319000 -0400
@@ -342,7 +342,11 @@ eFilePushThreadRecorder::eFilePushThread
     m_stop(1),
     m_buffer_fill(0),
     m_buffer_min_write(0),
-    m_messagepump(eApp, 0, "eFilePushThreadRecorder")
+    m_messagepump(eApp, 0, "eFilePushThreadRecorder"),
+    m_protocol(0),
+    m_session_id(0),
+    m_stream_id(0),
+    m_packet_no(0)
 {
     CONNECT(m_messagepump.recv_msg, eFilePushThreadRecorder::recvEvent);
 
diff -urpN a/pvrparse.cpp b/pvrparse.cpp
--- a/pvrparse.cpp    2026-04-11 20:33:44.495083000 -0400
+++ b/pvrparse.cpp    2026-04-11 14:47:52.780588000 -0400
@@ -922,7 +922,14 @@ int eMPEGStreamParserTS::processPacket(c
             //}
             //eDebugNoNewLine("\n");
 
-            return -2;
+            /* Return 0 (not -2): a missing/invalid PES start code means we
+             * cannot extract a PTS from this packet, but the stream is not
+             * corrupt — CI-decrypted streams, MPEG-1 audio, and similar
+             * sources regularly produce PUSI packets without a 0x000001
+             * start code.  Returning -2 caused parseData() to abort early
+             * and asyncWrite() to skip writing data to disk, resulting in
+             * empty recordings and missing .ap/.sc files. */
+            return 0;
         }
 
         if (pkt[7] & 0x80) // PTS present?
The pvr pvrparse.cpp edit could be at least questionable, depending on what -2 depends on as compared to the previous 0. So you can probably eliminate that one if you want, and really you can eliminate the whole commit because it has actually been fixed twice!

The filepush.cpp edit is what I see as actually fixing the problem, Which is basically adding:
+ m_protocol(0),
+ m_session_id(0),
+ m_stream_id(0),
+ m_packet_no(0)
Why this was missing in OBH engma2 will remain a mystery, but the same damn code has been in OpenATV since at least 2024:
ATV-filepush-2024- 2026-04-26 01-54-02.png

So there basically you have it. That is the total sum of our edits that are supposedly a Work-Around or whatever. Sure, the pvrparse.cpp edit may be wrong, but no one says that outright. Our filepush.cpp edit has existed in ATV code for years!

I built a custom image again from OE 6 sources and used this enigma2, which represents filepush.cpp and pvr.cpp before they were edited here:
github.com

GitHub - EB-TNAP/enigma2-OBH: openbh-gui

openbh-gui. Contribute to EB-TNAP/enigma2-OBH development by creating an account on GitHub.
github.com github.com
The image built from that source only produces 3 files for a CNN feed channel on Galaxy 19, tp 11795H
The OBH Test image only produces 3 files as shown here, NS CH4:
root@sf8008:/media/hdd/movie# ls
20260426 0126 - NS Ch4 - instant record.ts
20260426 0126 - NS Ch4 - instant record.ts.cuts
20260426 0126 - NS Ch4 - instant record.ts.meta
20260426 0138 - Srv_2 - instant record.ts
20260426 0138 - Srv_2 - instant record.ts.cuts
20260426 0138 - Srv_2 - instant record.ts.meta
20260426 0138 - Srv_2 - instant record.ts.sc
20260426 0158 - MontanaPBS - Current.ts
20260426 0158 - MontanaPBS - Current.ts.ap
20260426 0158 - MontanaPBS - Current.ts.cuts
20260426 0158 - MontanaPBS - Current.ts.meta
20260426 0158 - MontanaPBS - Current.ts.sc
root@sf8008:/media/hdd/movie#
What fixes it? The same thing ATV has been using in filepush.cpp for years: m_protocol = m_stream_id = m_session_id = m_packet_no = 0;
Apparently someone realized this or saw this and added it yet again here:
github.com

[filepush] reinstate missing initialisation statement · BlackHole/enigma2@f3e9b81

leads to loss of .ap & .sc filesl
github.com github.com
This means the "fix" is duplicated and exists twice in OBH, filepush.cpp, but only exists once in OpenVix filepush.cpp. And this is why I say you can probably eliminate mine entirely as I tested without the pvrparse.cpp edit and got all of the recording files. The real and proper fix it seems is in filepush.cpp, but you got it twice currently in OBH filepush.cpp, once from me and again, courtesy of OpenVix commit!

So where may I ask is the work-around?
 
You must log in or register to reply here.
Back
Top