Capt.Insano

Community Developer
  • Posts

    273
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Capt.Insano's Achievements

Contributor

Contributor (5/14)

8

Reputation

  1. No, input shows a correct kp/s for the stream (usually about 3k). If I manually trigger/schedule the recording the input and output kb/ps are the same and the recorded file is being created. I have not seen anything in the TVheadend logs, it is as if TVHeadend thinks it is recording correctly but then after the recording realises that the file is missing. But I must check the logs again.
  2. I updated VM shutdown time-out to 180 secs and still a parity check after reboot. I have 3 VMs as you can probably see from prev logs: HomeAssistant VM (Hassio) PiHole (Debian Based) Windows 10 (With latest virtio-win-0.1.208 drivers installed) New diags (from USB key) attached. tower-diagnostics-20211020-0819.zip
  3. I am running this docker with the deafult (latest) tag. Current version: HTS Tvheadend version 4.3-1979~g8fc2dfa7e I am not sure if that is currently recommended or not? When recording via autorecs the recordings fail with a file missing error, the scheduled recording "starts" there is no file outputted: During a "recording": Status > Subscriptions lists the output as 0kb/s and there is no file created in the unRAID filesystem It is not a permission issue (either filesystem or user permissions) as: If I stop the autorecording and start it manually via either WebUI or Kodi the recording works correctly. The Priority and DVR Configurations for the autorecs are the same as manually triggered recordings but only manully triggered or schedued recordings work. I have tried searching this bug in regular tvheadend forums but got nowhere. Anyone here having the same issue?.
  4. I did, infact they were already installed but I also updated them and all drivers to latest stable: virtio-win-0.1.208
  5. I followed your recommendation of changing my VMs to hibernate instead of shutdown, any other recommendations seeing as libvirt is the culprit?
  6. Anyway of figuring what was using Cache? If I monitor top/htop during a shutdown would that tell me?
  7. @JorgeB Sorry, I didn't realise there were other logs: Attached are the 2 zips dated today from /boot/logs Are these the diags that you were after? Thanks for the help BTW tower-diagnostics-20211019-0953.zip tower-diagnostics-20211019-1001.zip
  8. Hi @JorgeB, Diags were attached to the post above yours, these were the diags from the latest unclean shutdown (this morning) that caused the parity check again. I will try and stop the array manually again and time it when I get home but as per one of my prev posts above; the last time it took 1 min 9 secs to stop and the disk timeout in my settings is now 180 secs
  9. Spoke too soon, Just tried another clean reboot there and again a parity check started after power up: Diags attached again. Any further advice? tower-diagnostics-20211019-1001.zip
  10. This seems to have fixed it. Increasing the timeout to a high vaue (180 secs in my case) has ensured enough time for safe shutdown even in the event of a Windows update during VM shutdown. Thanks @Frank1940. Update: See below, problem returned after array runnning for any length of time.
  11. I timed how long it took to stop the array from the Main tab: 1 minute & 9 Seconds. Could it be that 90 secs is not long enough in my setup for all my VMs (x3) and Docker Containers (x30+) to shutdown fully if something like a windows update kicks in? I am going to up the timeout to 180 secs and see if a parity check starts on reboot.
  12. Everytime I reboot or shutdown my system a parity check starts when it powers back up. I am aware from reading other topics that this usually means an unclean shutdown but there is no errors appearing in the syslog during the shutdown process. I have read a very similar topic here: I based on that topic, have tried replacing my flash-drive to a new one and have tried chaging the shutdown timeout as per this comment in above thread: "Timeout appears to be kicking sooner than it should, go to Settings - Disk Settings and change the shutdown timeout to a different value just to re-apply, set it to like 60 secs." But still I get a parity check starting after reboot. Diags Attached, I would greatly appreciate any help. Thanks to all. tower-diagnostics-20211018-1428.zip
  13. EDIT: Nevermind! Found the below comment that explains governors on Intel Pstate driver: _________________________________________________________________________________ Original Post: Under CPU Scaling Governor I have no option for ondemand, not sure if this is normal? Running unRAID 6.9.0: Is this as expected? Thanks a million for your work.
  14. I imagine this may be an issue for others so posting my experience here: After upgrade from 6.8.3 (all smooth), I removed the following from my go file: modprobe i915 chmod -R 777 /dev/dri I then created the blacklist override as per release notes and rebooted: touch /boot/config/modprobe.d/i915.conf This correctly loads the i915 module: root@Tower:~# ls /dev/dri by-path/ card0 renderD128 However the permissions seem to be an issue: root@Tower:~# ls -la /dev/dri total 0 drwxr-xr-x 3 root root 100 Mar 3 11:57 ./ drwxr-xr-x 16 root root 4320 Mar 3 12:02 ../ drwxr-xr-x 2 root root 80 Mar 3 11:57 by-path/ crw-rw---- 1 root video 226, 0 Mar 3 11:57 card0 crw-rw---- 1 root video 226, 128 Mar 3 11:57 renderD128 Emby will not use hardware transcoding unless I also issue the following command and then restart the container: chmod -R 777 /dev/dri As such I have added that command back into my go file. Is this the correct action to take or is there something else that sould be done regarding the permissions of /dev/dri for container usage? Congrats @limetech & team for another great release.
  15. I just download this container for the 1st time and I am getting the same errors in my log unRAID 6.8.3