Posts by popcornmix

  • LibreELEC on RP3B+

    Quote from charwhee

    2. My understanding is that RBP3 doesn't use standard (hardware) video acceleration, and will run worse on newer versions, so the best version to use is 9.2 since that was built pre-4 and has all the specialized video accelerations tricks for RBP built in.

    HW acceleration works fine on Pi2/Pi3 for h264, mpeg4, mpeg2 (with licence), VC1 (with licence) with latest kodi.

    The only loss compared to 9.2 is hevc decode. That had a heavily software accelerated decoder which used bits of

    arm simd, 3d shaders and VPU vector operations. Unfortunately that just wasn't possible to support when moving to

    standard linux api (v4l2 and drm).

    I'd recommend using the latest LE image, and avoid hevc encodes.

    If you need to play hevc, then stick with 9.2.

  • HiFiBerry Digi audio device sometimes not loaded?

    Okay - those logs look identical so the firmware is loading the device tree overlay (called HAT) correctly.

    Looking through the kernel log. This is the bad one:

    Code
    Feb 17 04:10:58.938161 LibreELEC kernel: wm8804 1-003b: Failed to read device ID: -121
Feb 17 04:10:58.938688 LibreELEC kernel: wm8804: probe of 1-003b failed with error -121

    and this is the good one:

    Code
    Feb 17 04:10:58.605877 LibreELEC kernel: wm8804 1-003b: revision E

    This feels like a hardware issue. You might want to try reaseating the HAT to make sure it's secure,

    and perhaps check the soldering looks consistent along the 40 pin header.

  • RPi4 LibreELEC-RPi4.aarch64-12.0-nightly-20230510 jerky playback

    Quote from LybsterKodi

    <<Do you have "adjust display refresh rate to match video" enabled.>>

    It was set off, I changed it to always but it didn't seem to make a difference.

    I then thought what happens if I set the display rate to 25fps and its almost perfect. I reset the refresh rate to 30 and rebooted but still jerky. Blundering about the wiki I manage to track down the entry for this and it says always isn't recommended - which of the two remaining is the best choice?

    On Start/Stop is usually recommended.

  • Libreelec 11.01 live TV freezes then crashes randomly

    Code
    2023-05-08 06:40:22.015 T:1112     info <general>: ffmpeg[0x3faf3a8]: [hls] Opening 'crypto+https://d2ce82tpc3p734.cloudfront.net/out/v1/97a6854b9b9147ee85165908bd78cfb7/master_19_20306835.ts?m=1683518436' for reading
2023-05-08 06:40:27.980 T:1112     info <general>: ffmpeg[0x3faf3a8]: [hls] Opening 'crypto+https://d2ce82tpc3p734.cloudfront.net/out/v1/97a6854b9b9147ee85165908bd78cfb7/master_19_20306836.ts?m=1683518436' for reading
2023-05-08 06:40:36.103 T:1118     info <general>: CVideoPlayerAudio::Process - stream stalled
2023-05-08 06:40:37.950 T:1117    debug <general>: CPtsTracker: pattern lost on diff 79999.000000, number of losses 1
2023-05-08 06:40:37.954 T:1117    debug <general>: CVideoPlayerVideo - Stillframe detected, switching to forced 25.000000 fps
2023-05-08 06:40:42.811 T:1117    debug <general>: CPtsTracker: detected pattern of length 1: 40000.00, frameduration: 40000.000000
2023-05-08 06:40:47.996 T:1112    error <general>: ffmpeg[0x3faf3a8]: [tcp] Failed to resolve hostname d2ce82tpc3p734.cloudfront.net: Name or service not known
2023-05-08 06:40:47.996 T:1112    error <general>: ffmpeg[0x3faf3a8]: [crypto] Unable to open resource: https://d2ce82tpc3p734.cloudfront.net/out/v1/97a6854b9b9147ee85165908bd78cfb7/master_19_20306836.ts?m=1683518436

    This is the key part of log. It looks like we are happily reading data from d2ce82tpc3p734.cloudfront.net, geting a chunk every 5 seconds until it fails. It's unable to resolve the hostname (a DNS failure).

    I suspect the problem isn't on the LibreELEC device, but somewhere on the local network (router if it handles DNS, but it could be another PC is you are running PiHole or some other DNS server.

    Can you try running (on the Pi or any linux machine* on network):

    Code
    while : ; do ping -c1 d2ce82tpc3p734.cloudfront.net || break; sleep 1; done

    It should run forever but will stop if you get a failure.

    (*) ideally a machine that doesn't do DNS address caching.

  • Raspberry 4B + rclone w/GDrive video glitches (green pixels at bottom) each 5 mins

    Quote from EloyFarina

    I know that hardware can't decode all the codecs, but, is my Raspberry Pi faulty? Because I notice that this issue is very random, I mean, if I notice the issue and I rewind some seconds the issue is not visible, but in 5 minutes appears again in other part.

    Do you have access to another Pi4? The usual way to provide evidence of a hardware fault is to swap the Pi over (leave sdcard, power supply, display, cables etc unswapped). If problem no longer occurs it is likely hardware. If it still occurs it is software (or located within the unswapped parts).

  • [unofficial] LibreElec (Nexus) 11.0.1 for RPi3

    I'm afraid MMAL is a bit of a black box to me - I've not worked on the internals.

    I've just used it a client, and like you, have had a number of hard to debug issues.

    One thing you need to be careful of is the MMAL callbacks are run from the normal MMAL processing thread.

    If you block in the callback you will stop any further progress.

    So callbacks should never block. If you need to do blocking work, then you need a separate task and just signal it from the callback.

    I'm a little concerned that ProcessOutputCallback may do that.

    Attaching gdb after things have locked up and looking at the threads that are blocked may be illuminating.

  • [unofficial] LibreElec (Nexus) 11.0.1 for RPi3

    Quote from ardaoktay

    As I've said, it's not based on your implementation of LE9. I didn't use any OMX components to render. I also didn't use port connections between decoder and renderer. But video_render component crashes on some occasions even if input port buffer release callback happens. I tried to flush renderer queue on input format change. I think the problem happens because there is always a single buffer left in the renderer, and I can't tell if it's used by firmware or not before disabling/flushing the port.

    Is there any reliable way to determine the buffer is no longer needed by the renderer component?

    Just to clarify LE9 has two independent HW acceleration methods, MMAL and openmax.

    The (default) MMAL decoder uses the MMAL renderer and doesn't use openmax in any way.

    MMAL works with buffers that you submit (mmal_port_send_buffer) and receive (through callback function given to mmal_port_enable).

    The rule is once you've submitted a buffer it is owned by the firmware until it is returned in the callback.