Erik Slagter

 

 

only having the sound of the main screen and the full video of the PiP.

So how you achieved this? There is no audiopip plugin in the feed available, and for some events like f1 I just need the audio from another channel while watching other ch on full screen...

 

On VU+ you can only gets audio from the main screen and not from the PiP. I have been told that there is no audio decoder in the chipset that handle PiP so it is not possible to have PiP audio.

This was possible on my Xtrend ET-9000.

Over here it works (Ultimo4k), try it with QuadPiP. So I guess it's possible, it's just not implemented in Enigma right now. I hear a feature request coming there 

Actually I can shed some light here, as apparently the issue not quite understood by many people.

To start with, this issue is not specific for picture-by-picture PiP, but it may show there as it requires both outputs to be quite large, whilst in "normal" PiP mode, the PiP video output is usually quite small.

Then, this issue is not VU+ specific, it's not even model-specific. It's just that VU+ uses other SoC types then most other manufacturers (more expensive, less basic), so they have their own limitations.

So yes, this is a limitation, not a bug. The SoC from the VU+ Solo4k and probably Uno4k(SE) too is limited in the PiP size that can be shown. Furthermore the actual size of the PiP depends on the position on the screen. So the window can be quite large when it's in the upper-left corner, but needs to be smaller gradually when moving to the lower-right corner. VU+ "solved" this issue in the drivers by accepting all possible coordinates, but apply a "correction" so the PiP window's size and position never get invalid.

IIRC GigaBlue or QViart have receivers with the same SoC and they're not applyting this correction. The result is garbage on the screen and possibly crashing. So what VU+ is doing, isn't that bad actually.

The interesting thing is that the SoC's of the Duo4k and the Duo4kSE/Ultimo4k (same SoC) do not have this limitation, they have really high end SoC's, that include four completely independent video decoders, which are also used for the QuadPiP feature. In theory it would be possible to use all of these as independent PiP sources, but we never looked into it, as it's not really interesting for the end user.

So we asked VU+ to lift the limitations for the SoC's that don't need it and they did. So the Duo4k, Duo4kSE and Ultimo4k do offer random positioning of the PiP and I can confirm that picture-by-picture really works.

So the bottom line is: if you want random positioning of PiP, you need a high-end SoC, so a more expensive receiver. For PiP you need (an) extra video decoder(s), which are expensive if added with full functionality.

Yes indeed. I would suggest that anyone having recording issues, for the moment disable timeshifting (either automatic or manual). If the error is gone then, we know where to search.

Also, the huge amounts of interrupted reads seem to be a sign that the stopping, later on, will not succeed. Can you confirm that? That during a normal, succesful recording, you do not get the huge amount of interrupted reads? That would also be an interesting pointer.

box got just stuck, trying to start playback of a recording.
box was in timeshift, but no signs of a record stopping in the debug log:

2023-08-27T16:41:56+02:00 stb1.swabian.net enigma2: [Network] Getting attribute:  ip  for adapter:  eth0
2023-08-27T16:41:56+02:00 stb1.swabian.net enigma2: [Network] Getting attribute:  netmask  for adapter:  eth0
2023-08-27T16:42:11+02:00 stb1.swabian.net enigma2: [Network] Getting attribute:  ip  for adapter:  eth0
2023-08-27T16:42:11+02:00 stb1.swabian.net enigma2: [Network] Getting attribute:  netmask  for adapter:  eth0
2023-08-27T16:42:14+02:00 stb1.swabian.net enigma2: [RDS] radiotext str: (+++ Merz sieht Deutschland vor großen Herausforderungen)
2023-08-27T16:42:14+02:00 stb1.swabian.net enigma2: [Screen] Showing screen 'RdsInfoDisplaySummary'.
2023-08-27T16:42:24+02:00 stb1.swabian.net enigma2: [ActionMap] Keymap 'OkCancelActions' -> Action = 'ok'.
2023-08-27T16:42:24+02:00 stb1.swabian.net enigma2: [eDVBServicePlay] timeshift
2023-08-27T16:42:24+02:00 stb1.swabian.net enigma2: [Screen] Showing screen 'InfoBarSummary'.
2023-08-27T16:42:24+02:00 stb1.swabian.net enigma2: [Screen] Showing screen 'InfoBar'.
2023-08-27T16:42:24+02:00 stb1.swabian.net enigma2: [eDVBServicePlay] timeshift
2023-08-27T16:42:24+02:00 stb1.swabian.net enigma2: [eDVBServicePlay] timeshift
2023-08-27T16:42:24+02:00 stb1.swabian.net enigma2: [Skin] Parsing embedded skin '<embedded-in-Screensaver>'.
2023-08-27T16:42:24+02:00 stb1.swabian.net enigma2: [Skin] Processing screen '<embedded-in-Screensaver>', position=(0, 0), size=(1920 x 1080) for module 'Screensaver'.
2023-08-27T16:42:24+02:00 stb1.swabian.net enigma2: [Skin] Parsing embedded skin '<embedded-in-HideVBILine>'.
2023-08-27T16:42:24+02:00 stb1.swabian.net enigma2: [Skin] Processing screen '<embedded-in-HideVBILine>', position=(0, 0), size=(1920 x 7) for module 'HideVBILine'.
2023-08-27T16:42:24+02:00 stb1.swabian.net enigma2: [Screen] Showing screen 'HideVBILine'.
2023-08-27T16:42:24+02:00 stb1.swabian.net enigma2: resolved to PLAY
2023-08-27T16:42:24+02:00 stb1.swabian.net enigma2: [eDVBServicePlay] unpause
2023-08-27T16:42:24+02:00 stb1.swabian.net enigma2: [Skin] Processing screen 'VideoMode', position=(127, 67), size=(600 x 75) for module 'VideoMode'.
2023-08-27T16:42:24+02:00 stb1.swabian.net enigma2: [Skin] Processing screen 'PVRState', position=(192, 172), size=(225 x 45) for module 'PVRState'.
2023-08-27T16:42:24+02:00 stb1.swabian.net enigma2: [HelpActionMap] removed duplicity: InfobarSeekActions ('jumpPreviousMark', 'Jump to previous marked position')
2023-08-27T16:42:24+02:00 stb1.swabian.net enigma2: [HelpActionMap] removed duplicity: InfobarSeekActions ('jumpNextMark', 'Jump to next marked position')
2023-08-27T16:42:24+02:00 stb1.swabian.net enigma2: RemovePopup, id = ZapError
2023-08-27T16:42:24+02:00 stb1.swabian.net enigma2: [Navigation] playing:  1:0:0:0:0:0:0:0:0:0:/media/hdd/movie/20230824 2125 - NGC HD - Air Crash Investigation.ts
2023-08-27T16:42:24+02:00 stb1.swabian.net enigma2: [eFilePushThreadRecorder] stopping thread
2023-08-27T16:42:26+02:00 stb1.swabian.net enigma2: [gRC] main thread is non-idle! display spinner!

strace available as well
(by the way, disabled deep standby by change in /etc/rc0.d/S90halt - box will just reboot.)

Can you change the setting "show zap errors" to "disable" (just to check)?

Also can you, when this happens, login to the receiver and check whether enigma is waiting for the buffer cache to flush?

You can do that by writing a chunk of data to the same disk (local, afaik) as enigma is writing it's recordings to and see if it returns in a reasonable amount of time. Something like

dd count=1024 if=/dev/zero of=/hdd/testfile status=progress; sync

You can remove the file afterwards. I am suspecting harddisk can't keep up with the data, for whatever reason, data is filling memory, and at some moment, the kernel decides there is no more memory available for buffering and blocks all writing threads until enough data has been written and cleared from the buffer cache.

That could also explain why we (Wanwizard and I) are not experiencing this, as we're recording to a NAS (using NFS).

There is also another difference between recording on local disk and a NAS: signals can interrupt I/O system calls and if that happens, the calling process gets a status "this system call has been interrupted" (EINTR) and how much of the data has actually been written or received. The process can then handle the signal and continue where it left. The premisse in the code is that this works. There is a caveat though. For devices that are deemed to be always available and quick to write (and a local disk is one of them), the I/O system calls cannot be interrupted. Not even a ^C or sigterm or sigkill will abort the system call. That means the code does not 100% works like it's designed; as long as data is ready to write (and not written), the thread will not gain control, it will remain in the system call until it's finished, however many signals are sent. As most of the time, a write system call to harddisk is quick to return, that is not necessarily a problem, but if the disk is slow, for whatever reason, the system call can be long to complete and maybe, just maybe, a blocked signal can get lost in that situation.

There are a few other paths I am exploring here:

- it's very interesting that the read() gets interrupted many times, even though all signals besides sigusr1 are blocked. What is that signal we can't block (as system calls can only be interrupted by signals). If that is a sigusr1 from another source (for whatever reason), we can have the situation where one spurious and one proper signal is to be delivered and at that moment the blocking is still active (at the start). Blocked signals always only have one instance queued, so the proper signal might get lost in that case. Maybe we should try using another signal, like sigusr2, as enigma is using sigusr1 at other locations as well. Better be safe than sorry.

- if we really don't get this working, I am willing to try a construction where we're not using signals at all, that is possible.

In the meantime I now have an up-and-running OE environment again, so I can try and test some things.

ran a 5 minute strace, afer box got stuck this morning.

don't know what exactly to look for.

it's mostly repeating:

[pid  1530] 10:55:53.097054 ioctl(8, _IOC(_IOC_NONE, 0, 0x22, 0), 0x12) = 0
[pid  1530] 10:55:53.116929 futex(0x343be0, FUTEX_WAKE_PRIVATE, 1) = 0
[pid  1530] 10:55:53.117073 futex_time64(0x343c20, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1692953753, tv_nsec=502132989093597259}, FUTEX_BITSET_MATCH_ANY) = -1 ENOSYS (Function not implemented)
[pid  1530] 10:55:53.117215 futex(0x343c20, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1692953753, tv_nsec=216911947}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out)

strace1.txt

 

maybe I will run enigma2 with strace tonight, to see what happens meanwhile the box gets stuck again.

Interessing that in this trace, there are no reads or writes whatsoever. There are some poll()'s, but I can't relate them to filepush.c.