Posts by JurKub

  • How to configure Atric IR-WakeupUSB with RPi4

    Quote from mglae

    As work around create a systemd drop in file to make the required directory:

    Code: /storage/.config/system.d/lirc.service.d/lockdev.conf
    [Service]
ExecStartPre=-/usr/bin/mkdir -p /var/lock/lockdev

    your work around didn't work

    Code: console command
    systemctl enable lockdev

    This one is working after the above console command but may not follow the rules of systemd

    Code: /storage/.config/system.d/lockdev.service
    [Unit]
Description=Workaround for LIRC issue
After=lircd.service

[Service]
ExecStart=/usr/bin/mkdir -p /var/lock/lockdev

[Install]
WantedBy=multi-user.target
    Quote from lwing

    How did you find out, that the lock file is missing, are there any logs for lirc in libreelec?

    If you are looking for logs have a look at this folder:

    smb share: Logfiles

    or

    /storage/logfiles

  • How to configure Atric IR-WakeupUSB with RPi4

    Quote from lwing

    How did you find out, that the lock file is missing, are there any logs for lirc in libreelec?

    Hi lwing

    good to hear my investigations helped to get your system working. :)

    I opened a PuTTY session:

    Code
    killall -9 eventlircd
killall -9 lircd
/usr/sbin/lircd -O /storage/.config/lirc_options.conf --nodaemon /storage/.config/lircd.conf

    In another PuTTY session I'ved started:

    Code
    /usr/sbin/lircd-uinput -O /storage/.config/lirc_options.conf --add-release-events

    After that I got an error message about the lock file in the first PuTTY session.

    Cheers
    JurKub

  • How to configure Atric IR-WakeupUSB with RPi4

    Hi all,

    need to come back to this old thread because of issue when upgrading from LibreELEC 10.0.4 to 12.0.1.

    The driver tries to creates lock files in /var/lock/lockdev which is not existing.

    In LibreELEC 10.0.4 the drives uses /var/lock

    Workaround is to create it using autostart.sh.

    Any ideas how to fix it without workaround using autostart.sh ?

    Thx
    JurKur

  • NFS performance issue

    fhemraspi:~ # cat /proc/sys/net/ipv4/tcp_wmem

    4096 16384 4194304

    fhemraspi:~ # cat /proc/sys/net/ipv4/tcp_rmem

    4096 131072 6291456

    fhemraspi:~ # cat /proc/sys/net/ipv4/tcp_window_scaling

    1

  • NFS performance issue

    Guys thx for your passion :)

    I believe it's an rsize / wsize issue of the Raspi NFS Server

    Nevertheless what I enter on client site using mount for rsize and wsize the value don't change :(

    For me it looks like it is hard coded into the Raspi NFS Server or I'm to stupid to find the way to change it :cry:

    NFS mount (rsize=131072,wsize=131072)

    Code
    10.0.0.53:/srv/vdr/video on /storage/videos type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.0.0.53,mountvers=3,mountproto=tcp,local_lock=none,addr=10.0.0.53)

    Samba mount (rsize=1048576,wsize=1048576)

    Code
    //10.0.0.53/recordings on /storage/recordings type cifs (rw,relatime,vers=2.1,cache=strict,username=vdr,uid=0,noforceuid,gid=0,noforcegid,addr=10.0.0.53,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,bsize=1048576,echo_interval=60,actimeo=1)

  • NFS performance issue

    rsize and wsize don't change nevertheless what I'm entering

    Code
    10.0.0.53:/srv/vdr/video on /storage/videos type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.0.0.53,mountvers=3,mountproto=tcp,local_lock=none,addr=10.0.0.53)
/

  • NFS performance issue

    Quote from frakkin64

    One other thing to consider here is perhaps NFS locking is an issue, especially if you are trying to watch a file that is being written to (i.e. trying to watch a live recording being written by VDR). Probably worthwhile to ask this question on the VDR forums, as you will probably find someone with similar setups. Tvheadend & MythTV work completely differently, everything is streamed by Tvheadend or MythTV, client doesn't access the recorded media files directly.

    There is just too much opportunity for speculation here with very little data, unfortunately.

    I don't try to watch a live recording being written by (another) VDR.

    It doesn't matter if I watch a VDR recording or another mp4 video, same issue.

    I'm more than happy to provide as much data you like, just ask for what you need to see ;)

  • NFS performance issue

    Quote from frakkin64

    I am running Tvheadend with 6 tuners (2 tuners are over Ethernet, and 4 tuners are in a PCI card in the computer) on an AMD 8-Core machine with 20TB storage, it has no problem recording all tuners at the same time, plus serving 2 medacenter devices over NFS. It serves both my media library and Tvheadend content (which is over HTSP [TCP]).

    Have you ran bcmstat.sh on your Pi to get more insight? I would run it with: "bcmstat.sh xce ieth0", you might need to change the eth0 to your network device. I would run that on your Pi hosting the storage, it will give you good visibility to your RX/TX network plus CPU/MEM usage. You might need to check your kernel settings for the number of NFS daemons running (on a Debian based system this is in /etc/default/nfs-kernel-server, changing RPCNFSDCOUNT). I run with 8 myself which is probably overkill since I don't have the overhead of writing to NFS over the network from Tvheadend like you do.

    This article has some advice on tuning nfsd threads:

    https://support.hpe.com/hpesc/public/d…mr_na-c02239048

    I don't think the Ethernet port is the issue, because using NFS for recording and Samba for replay at the same time everything woks fine

    /etc/default/nfs-kernel-server

    I've tied sync and async as well in

    /etc/exports

  • NFS performance issue

    Quote from Klojum

    What OS is running on the RPi4 server with 4TB?

    Linux fhemraspi 5.10.63-v7l+ #1459 SMP Wed Oct 6 16:41:57 BST 2021 armv7l GNU/Linux

    Quote from Klojum

    Handling files is a relatively demanding job on a CPU for a RPi, both USB30 and Gigabit ports really only work at half speeds in my experience. So depending on the overall bitrate of the VDR streams, it's possible that the RPi4 is simply not up to the task, despite having set up NFS correctly.

    I wondering using NFS for recording and Samba for replay at the same time everything woks fine.

    The problem exists only when using NFS for recording and for replay at the same time !

  • NFS performance issue

    Hi guys,

    when VDR-Office is doing more the 2 recordings at the same time replay on VDR-Living is chopping, both using NFS.

    If I do the repay on VDR-Living using Samba it works fine.

    This is a rough drawing of my LibreELEC setup.

    NFS mountings:

    VDR-Office:

    /storage/videos -> FhemRaspi:/srv/vdr/video

    VDR-Living:

    /storage/videos -> FhemRaspi:/srv/vdr/video

    FhemRaspi /etc/exports:

    Any idea what I need to change to get it working all using NFS ?

    Thx

    JurKub