s.Oliver

certainly, but how likely (in the light how long this 'bug' exists) this is?

hmm… no reaction (beside himisk71)? dare i ask the logical question? would it be possible to get a docker version of TVHeadend, based (like tested) on Ubuntu, or any other distribution (of docker builders choice) which fits the obvious glibc requirement? i (and i'm sure a big bunch of other users) would absolutely appreciate this effort, as we all get a fully functional TVHeadend. and… as a side benefit to the linuxserver.io team, no more questions about these crashes (so no one could think, it's a defect in the docker provided). wouldn't that be a great christmas present to the unRAID community? as a reminder to all users who benefit of the great generous work of the linuxserver.io team: they accept donations.

BREAKING NEWS --- g o o d b r e a k i n g n e w s i followed @saarg's tip to try that xenial_test docker; low and behold (ah well, i had that feeling in the stomach area) it finally works. the docker had TVHeadend 4.3-48~g633744d version installed – tried to run it with my pre-populated appdata folder (TVH 4.2.x) but it error'ed in a loop because of not being able to create a backup with the /bin/tar command (this worked however with 4.2.x and latest:4.3.x versions) – did then a clean setup this resulted in: – any recorded file could be played back perfectly (click on play icon downloads these small files) which then (can be/or are automatically) opened by VLC and playback starts – you can change playback position to anywhere in the recording – even while a program is recorded, you can (live tune-in)-playback the same channel without interruption of the recording alerts - [ ALERT] settings: Unable to create dir "/config": File exists (this seems to log always 3 times in a row when a playback/or recording starts) so this seems to be the solution (glibc vs. musl) to have a great (much improved) TVH experience; right here on unRAID

no hurry, no hurry.

well i could try to help (as much as i can, but not a real linux guy – will probably limit my possibilities). but then could we try another approach first? could we built (for testing purposes only) a version of the TVH container, which is based on another linux, which then has glibc? if that one would show the same bug = probably a TVH bug, but if not (and it works) it's not a TVH bug (and somehow i imagine it's like that). @saarg: great thought/idea, that it's maybe because of the glibc vs musl (may i ask if you guys had similar experiences with other containers build on alpine linux?)

oh no, not for docker on unRAID. i meant, when you setup a VM on unRAID and installing TVH inside the VM. so which template you choose for the VM, which hardware specs you give it (ram, cores, etc.), which linux distro/version you install and on top of that how would you install/compile TVH then?

could you please provide some informations, as how you setup this VM? do you follow a guide to install/compile tvheadend?

no complaints here, i can't compare this docker version against a normal installation. it would be tempting to know (or learn), if the same version installed on a 'comparable' linux distro would yield the same problems, or not. or in an docker on another distro, to see, if we get the same crash. like @himisk71 said, his vm installation worked flawless. now what is the difference then? i would say it's a bit unlikely, that all versions show the same bug/crash and that nobody from the programmers have heard of it, nor did they want to fix it. that would be a major drawback for the whole tvheadend project. could it be a docker (on our unRAID) implementations problem? i can playback recordings with kodi on embedded boxes (using the tvheadend plug-in) from the very same tvh-docker instance. @linuxserver.io team: no complaints against you guys. great work. with every build. thanks for that, it's appreciated alot here. but it would be cool, to get this nasty bug eliminated.

i had never before used tvheadend... but i think that talk was about docker versions.

would like to see a solution to this problem as well. it is a longstanding (tvheadend) bug. awhile ago i tried to dig up informations about this error and read on a site (can't say which any longer) something like "it needs to have transcoding support to be compiled in". maybe the linuxserver.io team (@saarg?) could confirm this. at least it would be a straw to grasp.

oh well, i'm sorry to have wasted your time here. curiously, something must have changed along the way... i had both plug-ins installed for almost all of my unraid time. there were one, two, three occasions, where the counts were wrong, but always an update of either one of the plug-ins then somewhen fixed it again. now it happened again, so i thought, it's maybe yours which needs fixing. thanks alot for being that patient and helpful. have a good night!

cha-ching! bingo! without it, the values are reported correctly!!!

yes, i have the latest installed.

Version 2017.10.29b (i did always immediately update).

thanks for the last update, didn't change anything. :-( to clarify myself from earlier postings: i used lsof (no argument) and then searched for the relevant parts (because of that the values were higher then right now). here are the actual outputs: ls -la /mnt/disks/ drwxrwxrwx 1 nobody users 80 Oct 18 15:16 Samsung_SSD_850_EVO/ drwxrwxrwx 5 nobody users 54 Oct 17 11:50 UDWD4TB/ lsof /mnt/disks/UDWD4TB/ COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME tvheadend 14733 nobody 51w REG 8,65 2994501788 14206387 /recordings/Recording1.ts tvheadend 14733 nobody 57w REG 8,65 152684764 14206397 /recordings/Recording2.ts tvheadend 14733 nobody 62w REG 8,65 3916977180 4311589916 /recordings/Recording3.ts UD shows 7 open files – correct value is 3 ---- lsof /mnt/disks/Samsung_SSD_850_EVO/ COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME qemu-syst 12310 root 18u REG 0,38 55810129920 262 /mnt/disks/Samsung_SSD_850_EVO/VM1/Name1/vdisk2.qcow2 qemu-syst 12310 root 19u REG 0,38 55810129920 262 /mnt/disks/Samsung_SSD_850_EVO/VM1/Name1/vdisk2.qcow2 qemu-syst 21566 root 22u REG 0,38 85001043968 258 /mnt/disks/Samsung_SSD_850_EVO/VM2/vdisk2.qcow2 qemu-syst 21566 root 23u REG 0,38 85001043968 258 /mnt/disks/Samsung_SSD_850_EVO/VM2/vdisk2.qcow2 UD shows 10 open files – correct value is 2 ---- so i think it's not too bad – unifying the results of both would lead to correct amount of open files.

that lists the correct amount of open files for the share without duplicates. ? but for the UD device without share it needs to be filtered for the process ‚duplicates‘ - in my case it lists 4 open files (double for each real physical file).

no and that‘s the strange part, UD does report opened files for it. i can‘t trace anything with lsof; not the device, not the share.

sorry to say no change in my case. more precisely: lsof only shows these 30 open files on only one UD device sdi (the SSD with vdisk images on BTRFS; auto mount, but no share); it looks like this: /mnt/disks/Samsung_SSD_850_serial/pathtofolder1/vdisk2.qcow2 (12x) /mnt/disks/Samsung_SSD_850_serial/pathtofolder2/vdisk1.qcow2 (18x) lsof doesn't show any references to the other UD device sde (HDD, XFS, auto mount + share); it is mounted to: /mnt/disks/WDdisk_serial share has custom name: /mnt/disks/UDWD4TB (i can't reference it with any parts of either 'sde' or it's name nor it's custom name).

dlandon, that‘s what i did. 32 processes reported the same 2 files as opened. UD reports 10. physically we have 2 files which are opened. i would expect UD to report exactly those 2. why report more?

well, in my case 32 processes have the same 2 files open. but that should result in (only) 2 open files displayed, right ?

well, have no screenshot at hand (will provide one soon), but in the past it was working absolutely fine (there was 1-2 times in the past, where it was wrong too, but a following update to the plug-in solved these issues always). let's say my tvh docker recorded 2 shows, UD showed exactly those 2 open files. now with a recording of 2-3 shows it provides completely other values like 8-10. live example: right now on another UD device (SSD) i have stored 2 vdisk images which are actively used from 2 VMs – UD shows 10 open files. lsof shows 32 hits, because of different processes using the same 2 files. just tell me, how i can help debug this error case. i'll try to help as much as i can. and free time is mostly a rare thing to have, so i do understand your comments about development. much more it is valued, that you take care. thx.

OPEN FILES count is wrong hey dlandon, thanks for a wonderful plug-in. i've had the issue in 6.4.0 RC9/RC10 definitely (and maybe also in 6.3.5 before) but can't say exactly at which plug-in it started (a guess could be 5-7 versions back). and may i ask, if we could get the same reads/writes column (with flippable switch between count of read/writes vs. speed)? ideally they would be aligned with the columns from the drives (above) of the array – so it would perfectly match optically and make it possible too check values with a quick view to it. i see it would be probably necessary to move the mount button much more to the right. hopefully you can fix the counting bug – it's quite useful feature. thx. alot, great work you do here.

stop the docker first, then run this command as root (mostly your root anyway in unRAID console): chown -R nobody:users /dev/dvb afterwards restart the docker.

mine looks mostly identical, but watch the permissions closely. i guess (and think to recall that) you need to modify those to match mine. drwxr-xr-x 2 nobody users 120 Oct 24 15:04 adapter0/ drwxr-xr-x 2 nobody users 120 Oct 24 15:04 adapter1/ drwxr-xr-x 2 nobody users 120 Oct 24 15:04 adapter2/ drwxr-xr-x 2 nobody users 120 Oct 24 15:04 adapter3/ i think your docker can't access those, because of insufficient permissions.

that works, indeed. i used :66 and am back to r11391 of oscam. my very first impressions is, it works as expected. but i want to test a little bit more, to see, that it's not a placebo effect.