LE9: Tvheadend42 does not answer/crashes with timeshift enabled (default)

  • Since I upgraded to milhouse builds later than june, my htpc locks up every 1-2 days. Locking up means i need to turn it off the hard way.

    I made same larger steps to september, end of october and latest. Since end of october at minimum one a day, often twice - hsts client complains it lost connection to tvheadend. After ~1minute it recovers. I guess tvheadend has been restarted. This seems not a hsts client issue as all running recordings at this restart are broken. The issues happened on hd and sd channels, often ofter a l long run time without any interaction with the system e.g. 2.5h on one tv channel.

    Where are the tvheadend logs? Any idea why the box completly freezes and need to be turned off? My users stressing because of this permanent instability issues. It‘s really annoying.

    Edited once, last by marc.bau ().

  • marc.bau

    Changed the title of the thread from “Tvheadend42 does not answer (restarted/crashed)” to “LE9: Tvheadend42 does not answer (restarted/crashed)”.
  • Sure, timeshift is the most uses feature...

    found it in /storage/.kodi/userdata/addon_data/service.tvheadend42/service.log

    That looks only the last. So if the machine restarted it get's overwritten. This makes it nearly impossible to find the issue. How can I enable cicular logging e.g. keep the last ~5 logs?

    Edited 2 times, last by marc.bau ().

  • Basic:

    • timeshift is set enabled
    • maximum period is 180min

    Advanced setttings:

    • storage path /storage/.kodi/userdata/addon_data/service.tvheadend42/cache/timeshift (780GB free)
    • Maximum size (MB): 10240
    • Maximum RAM size (MB): 1024
    • Ram only: disabled

    Expert settings:

    • all: disabled

  • Could you try to disable timeshift at ram completely?

    Also i need to improve the log stuff asap.

    Thats something that should behave better.

  • Yesterday I disabled timeshift completly as a try. Since the change I had no tvheadend crash or complete system freeze yet (day before it crashed 5 times), but well this need to be monitored longer to be safe.

    Your last comment sounds like there is a known issue? With ram only? Setting it to 0 disables it?

  • There are similar problems with timeshift at ram. I am unsure if the users just misusing it (2gb ram at system, 2gb for timeshift) or if there is a real problem.

    I use only timeshift at ram since >1 year without a single problem (to save my ultra cheap and crappy OS SSD).

  • Ok, after days of testing the issue persisted with timeshift to disk and ram disabled. After I completly disabled timeshift it seems to be stable now. I can try with timeshift to RAM only again. I have 4GB RAM, so 1GB timeshift should work well normally. But after this 1GB is full tvheadend automaticall moves the data to disk (at least documentation says this). This may explain why this issue persisted with timeshift to disk.

    I had only used normal HDDs for timeshift.

    Seriously... the #1 reason why I have a HTPC is timeshift feature. If this is broken the HTPC is really no longer a real benefit.

    Debugging such a reproducible issue should be possible... but how?

  • 2 hours ago, enabled timeshift to RAM only, 1 minute ago - crashed again. Disabled timeshift again :cry:. HTPC now useless.

    I only use the milhouse LE9 builds.

  • If tvheadend crashes the logs are always overwritten as the service auto-restarts.

    Can this logging issue fixed, so that I can share logs?

  • I guess you could manually start it.

    From memory

    systemctl stop service.tvheadend42

    cd /storage/.kodi/addons/service.tvheadend42/bin


  • Cannot belive I‘m the only having this issue. Since timeshift is disabled all is very stable. No crashes anymore.

    How about the improved logging?

  • How about the improved logging?

    found no proper way doing it :(

    but you can do it manually

    login via ssh and type

    tail -n50 -f /storage/.kodi/userdata/addon_data/service.tvheadend42/service.log

    that grep the log as soon it happens, if the box crashs you can still see the output of the log