Posts by JoeAverage

    I would run

    journalctl -u smbd

    directly after the smb server appears to be down (when it was running before)

    or run it with "-f" ("f" for ~follow up~) all the time

    journalctl -u smbd -f

    or

    journalctl -f


    to see all what's up with your box

    maybe with increased log level:

    [Chapter 4] 4.8 Logging Configuration Options


    ===

    btw.:

    the smb server box is connected via ethernet, too ?


    ===

    maybe something in your smb.conf is ~slightly~ wrong (full wrong => smb wouldn't start)

    run [1]

    testparm -v


    I'm unsure here: I guess it cry's when error are found, anyway I fetched the return status via "echo $?" where I guess "0" means no errors


    one of this has caused trouble for some users (I guess the first one)

    server max protocol ?

    server min protocol ?


    [1]

    I've attached the output of testparm -v

    be aware:

    - it's from nightly

    - it's the untouched default, cause smb is here NOT in use


    if you've a linux box available you could e.g. use "meld" to compare yours and mine

    Meld


    There is nothing in the log that helps solving the problem:

    journal log files are thrown away when you reboot the box ...

    and you just checked for smb only, so maybe it's not smb (my bet: it's network ...[if you don't find any weird config settings with testparm] or it's something with the kernel)

    last part could be checked with nightly (newer kernel: 5.15.y)

    my 2 ct:

    - did you compared the TvH setting (Pi3/Pi4) e.g. made a photo with a digicam/smartphone ?

    - if you're still in possession of the elder TvH setting [1] why not copy it over somehow with a subseq. reboot ?

    - try TvH 4.3 if available (?! ) from here:

    Tvheadend nightly builds for LibreELEC


    I don't know if RPi2/3 will run on RPi4 too !


    [1]

    I guess it's this file

    /storage/.kodi/userdata/addon_data/service.tvheadend*/config

    just checked

    Host: fedora 35 on an Intel i5-11400


    GPU:

    - Video Mem. :128 MB

    - Graphic controller: VMSVGA

    - Acceleration: enable 3D A.


    with I got the LE-VM up, but the installer doesn't not see a disk to install on.

    running it with "run" I got for storage (Size/Used)

    - /flash 511,7M / ~264M

    - /storage 26.5M / 7,7M !




    VGA seems to be a LLVM

    AFAIK it's a GPU in software


    anyway, I've read to get an usb stick bootable in Virtualbox.

    with that there is maybe a chance to get an LE release or nightly installed ...


    I need more time to play with it somewhat more, don't know when ...


    liberi are the VM bits on in your Bios ?

    I would have tried the H2testw but my German is limited to Please and thank you.

    well, "german" "download" is the same as the english "download" ;)

    the file downloaded and unzipped provides an (english) readme !


    other way:

    *long* format the stick under windows and "chdsk /F ..." (see: chkdsk /?)


    dumb question:

    you tried the windows install usb stick on a windows box ?


    hint:

    with an the windows installer stick, even with elder GPU's, it needs some time until the setup/install window appears (seen with elder Intel GPU, HD4000, Ivy Bridge)

    time to shovel ~4GB (win10) from an slow (?) usb stick into RAM !

    So....I fired up my Linux Mint machine but couldn't download the gz file

    md5 checksum to compare:

    da23178c4b1d9700842d7df9386e95e6 LibreELEC-RPi2.arm-11.0-nightly-20211127-b9d3fa5.img.gz


    it's the last but one file in the list from comment #5


    and for the LE usb creator:

    3e094fac708fa3008864260e820ba1c7 LibreELEC.USB-SD.Creator.Linux-64bit.bin

    I decided it's time for a shiny new RPi4 so that's my next project and I understand. I'm still stuck on the sd-usb creator issue. I've prepared two different usb sticks of different brands and sizes and neither will boot up on my Windows PC. I have a few other usb sticks with LE9.2 on them which still boot up just fine. What would cause this?

    maybe a test with an window install image to exclude it's the usb stick itself:


    on windows:

    open a terminal with admin rights and key in the following commands (all after "#" are comments not commands !) :

    diskpart

    list disk

    select disk N # adjust "N"

    detail disk # to see you selected the correct disk

    clean # cause this will move your data to /dev/null 8)

    create partition primary

    format fs=ntfs quick

    assign

    active

    exit


    now unzip [1] or mount under linux a windows install dvd and copy the content to the stick


    does the stick boot (now) ?

    no: [2]



    [1]

    don't known if the windows buildin zipper is that smart.

    if not:

    Download


    [2]

    H2testw
    H2testw erkennt gefälschte USB-Sticks, indem es deren tatsächliche Speicherkapazität ermittelt. Auch andere Wechselmedien sowie Festplatten lassen sich testen.
    www.heise.de


    from the included readme (please read at first !) :

    "... H2testw was developed to test USB sticks for various kinds of errors. ..."

    - I've NO idea of "Pi OS Lite" [1] -


    but maybe you could get some useful output if you open two terminals on the nfs server:

    - one running dmesg -w or journalctl -f to see what is happening

    and

    - one running sudo exportfs -ra ( or -rav)

    see: man exportfs


    you could also mount the exports on the nfs server itself to see if all is working.

    if this is all working (local mounts) you should investigate your network (firewall, etc., maybe starting with simply pinging each others, ...)


    IIRC (long ago playing with nfs) a simple wrong placed blank in /etc/exports caused long lasting "fun"...


    [1]

    did you investigated on their forum (if available) too ?

    some questions:

    1. did your lan setup ever run or is it a regression ( I esp. mean: simultaneous recording and replaying) ?

    2. you said running SMB is fine, why don't run SMB [3.1 ?!] only ?

    3. why are you shoveling big data through an LAN ?

    I esp. mean when all 4 satellites on the intel box are recording

    why not store the data where they first appear (at the intel box) ?

    4. what does the network traffic and the CPU load on an PI look like when doing 4x recording *and* 4x replaying concurrently (!) ?

    did you checked it with htop, etc. ?


    - I've no idea from PI or FHEM or VDR) -

    5. but isn't the intel box a lot more potent then the PI and wouldn't it make more sense to run a NFS server on the intel box too and in the dependence of what OS is currently running on the intel to maybe use a newer version of NFS (4.x) / kernel ? [1]


    [1]

    newer mostly means "better", but the opposite might also be true (sometimes it is, but sometimes only !)

    I guess you're nailed with an aged kernel on the PI ?

    I've read newer kernels benefiting from more throughput ...


    I've currently also no idea if NFS 4.x provides any benefit over 3.x, but usually a newer version fixes the bugs/shortcommings in an elder version ... (sometimes :saint: )


    or I'm to stupid to find the way to change it

    /etc/nfsmount.conf


    see:

    https://man7.org/linux/man-pages/man5/nfsmount.conf.5.html


    clear (?): adjusting {r,w}size => no need to provide them as mount option (client) - I would like to say - dito: Proto, etc.

    ===

    btw.: google is also a search engine :cool: