Jump to content

s.Oliver

Members
  • Posts

    308
  • Joined

  • Last visited

Everything posted by s.Oliver

  1. 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.
  2. 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).
  3. 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?
  4. well, in my case 32 processes have the same 2 files open. but that should result in (only) 2 open files displayed, right ?
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. Yeah, strange thing. That site was up for years and suddenly it disappeared.
  11. @saarg maybe it's only cosmetic, but that latest oscam update (you switch to another source for oscam, right?) shows as build version r0. which version actually is it? same as the last one from the streamboard source? why i ask? you know my problems with tvheadend (posted on the tvheadend thread) since just a few days ago. in between i setup a complete new server (docker setup complete from scratch, incl. new usb stick in trial for unRAID) everything possible to think of (other destinations for recordings, etc.) – and now i'm struggling to find any other reasons, why my rock-solid tvh-docker has these super strange problems. and maybe, that would be my hope, maybe it's because of that new oscam build; that could explain alot and from the timeline would fit into this scenario. question: could i please ask for that docker build before the change? i remember it was something like r11391. that would be awesome. (i haven't found any tipps in regard of specifying a targeted version which to pull for the docker). thx. alot saarg, i hope you can help me out.
  12. thx. for that. i did yesterday a re-install (and even a total rebuild of the docker.img) of the release:4-2 and also got the same version than you. but, i got a whole new bunch of problems, all fixed but one: some recordings just write the first few B/KB in the file and then it suddenly stops. Status / Abonnements shows still incoming data but nothing for outgoing – so the file isn't growing in size. the files are too small for inspection with a video editor (complains immediately that no video titles can be found). i never had this error before (with really alot of recordings happened). i use an unassigned drive as destination. since that, i did several re-installings (even back to latest 4.3.556) all show now the same problem. whenever a file is grown bigger than a few Bytes/KiloBytes it is finishing successfully. i checked logs from TVH/unRAID and there's nothing to see, all is like it always was. i'm pulling hairs now, because suddenly TVH has become unreliable in doing recordings. damn, wish i never had tried to get this version/updating stuff working. btw: again an update ready was shown for TVH release:4.2 docker, with (then) nothing to update – oh well. i'm still on unRAID v6.3.5, if that matters. more infos: it seems to be happening every 3rd/4th recording. and just now i had the case, that even if i aborted the recording and started it again it would not succeed – 4 tries 4 times the same result. but i could immediately live-stream this channel without problems. so this proves (in my opinion) that it is related to writing data to disk (and so maybe even not a TVH only problem). but then, i have not changed anything unRAID related beside the re-/new installation of TVH/dockers. bang. puff. dead.
  13. well, we'll see what happens, i keep you posted here. need to get it addressed anyway, because always getting the impression/post of having an update is driving me mad.
  14. ya, saw it just a few secs ago also. and that's the stable release then, probably, right? so mine is behind. will try to do a new install and see what happens then.
  15. hihi, i did that in the past somehow i never understood which version was which tree (stable, unstable, development). well, this time i see this: that would probably fit (if it's the same tree). but that means that my docker is with 4.2.3-39 way behind.
  16. ok, do you know the latest version in the release-4.2 as of yet?
  17. hey guys, i reverted back to the "linuxserver/tvheadend:release-4.2" version and wanted to report/check for one failure/feature seen here with the update process of the docker. my installation of TVH shows this version "HTS Tvheadend 4.2.3-39~ge195d1845" as installed (i guess it was that version from start on). now, every time when dockers get checked for newer versions, i get notified that there is a newer one for TVH. letting it update doesn't resolve to any other/newer version – it stays the same. while it's showing the updating dialog there doesn't get one new part downloaded (it takes just 2-3 secs); so actually it ends in a pure restart of the docker with the same version. is it a known problem (bug) with version checking? has anybody the same? thx. and have a good day.
  18. well, i read it, buy maybe i'm a little bit dumb here to understand the exact definition (wanted to make it a one time right setup, without much trial and error because of unRAID usage here, i would guess i need to add a custom variable while creating a new docker, right? if so, and i interpret a bit here, i could imagine it has to look like this: Name: my own name for it Key: linuxserver/tvheadend Value: release-4.2 Default Value: (can/must be empty?) if this is correct, then halleluja... please correct if wrong, else i can imagine, it helps quite a few people to see it simply put here. thx. as always :-)
  19. ok, want to chime in, because of different 4.3.x troubles i cope with. i also will revert back to the 4.2 branch, but with a 'small' twist. i will keep my old installation, because of all the recordings done – i need to be able to search, sort and delete them (i guess still no one has overcome the problem of keeping/adjusting old recordings into a new installation of TVH – and maybe it isn't really possible at all; only read a few lines about it). so when i'll install a second docker for TVH i'll have to set manually the tag 'release-4.2'. i would guess this will provide updates into the 4.2.x release as they (if ever) come. also i would think it will then update to the 4.2.1, right? i wouldn't want to set it to 4.2.1 straight and then maybe a few months from now a 4.2.2 will be released. but because my installation doesn't show any tag field (it's current 4.3.x) i would need to guess how this field must be called to serve as version tag field. saarg: could you just please give a straight simple line how it is called? thx. alot.
  20. ah, right – forgot that bug. safari shows this too – constantly reloading (and only showing the epg-tab); never completes and so can't use it. now i need to use a second browser (only for tvh). oh well...
  21. yep, noticed the change as well. since then, safari (on macOS) also only shows the epg-tab – nothing else (and btw. it even takes firefox a second or two before it displays the other tabs). before that change, both browsers did show all tab instantly.
  22. alright thx. i'll try that one (could get it faster and cheaper), but if it doesn't work will try the infinity usb smart one.
  23. found this one: "Smartmouse / Easymouse 2 USB Premium" all talk is that most linux'es support it directly (has an FTDI chipset). protocols supported: smartmouse / phoenix – does smartmouse here mean smartreader (or smargo) in oscam? what do you think of that one?
  24. yah, that would have been my next question (hey, how do you pulled that one – how far do brain waves travel?) ok, will probably look for one of those mentioned ones. might ask you then, if you think/know if it's supported.
×
×
  • Create New...