boragthung

Interesting. I was wondering really if it was all that necessary for the extra time in parity checking beyond the size of the data array, although as you say it does not stop normal usage of the system. I had a passing thought that maybe I had missed something in the settings that would distinguish between full parity disc check and full data size check. I suppose the extra time taken gives some peace of mind as to the reliability of that bigger parity disc. My only concern is the other week I actually got a warning about the temperature of the 8TB WD Red because it hit around 45C (normal use not parity check). It seems it generally runs 8-10C hotter than the 3TB WD Reds which I find surprising seeing at is has helium rather than air. Some net searching seems this is a common complaint. The weather was very hot though that week in the UK, hitting 38C in places. Since then (on another thread) because I was having issues with a satellite card, while I had the case open I added another 2 inlet fans to my Fractal Design Node 804 case - which does make it noisier despite the bios quiet fan setting. The disappointment here is I discovered the only way to add extra fans at the top of this case is to remove the hard disc cage holders, which seems to defeat the purpose of providing extra cooling to that side of the case. A good case otherwise.

Sorry I think you might have misunderstood what I was saying there. 8TB parity with all data drives 3TB. The first 3TB of parity checks all discs (the actual parity of array), but the last 5TB check is only checking the parity disc itself for errors and runs slightly quicker as it's just reading that one disc. In my case when I had a 3TB parity disc the check took over 7 hours, whereas now with an 8TB parity disc it takes over 17 hours, so the extra 10 hours is reading the parity disc alone.

OK thanks, so really in my example the (extra) parity check is really a test on that discs reliability beyond the current array size, just reading to confirm still zero.

I understand the basic principles involved but when the parity disc was first rebuilt new after replacing the smaller driver, it was my assumption that the last 5TB was all written zero. From this point on that last 5TB of parity disc would not actually need to be read or written to again until a point when another >3TB data drive is added. So does this mean even though no reads or writes need to take place yet to that last 5TB there could still occur errors here? A mysterious 1 appearing instead of a zero when nothing is being written to the area under normal operation? What would cause this, heat or some other interference maybe corrupting the magnetised area? Sorry to sound a bit thick - my brain certainly doesn't work like it did when I was younger :(.

I have a query about parity drives that are much larger than all the data drives. My system consisted of all 3TB WD Reds and a 3TB parity check would take something like 7-ish hours. I recently upgraded my parity to an 8TB WD Red and am using the old 3Tb as a data drive, the idea being that any future additions will likely be 8TB data drives. Now a parity check takes around 17 hours. So my question: After that first 3TB of actual parity checking the array, why does it continue with the (unused by data) last 5TB of the disc? Why is it necessary? I thought parity was only written to when the corresponding data address is written to. Unless I add a data disc bigger than 3TB that last 5TB should not be touched.

I have just ordered an Azurewave AD-SP400 I found available - which is the same card as the Skystar effectively (Skystar is re-badged version). Hopefully that will just slot in easily as uses the same drivers, only difference being system id.

Took my Skystar HD2 out of the server and put it in a Windows 10 PC, installed drivers and tested with DVBviewer transedit scanner and it is still failing to find any data so I must conclude that something on the card itself has stopped working so it is a hardware problem after all. Not happy about the hardware failing and don't know why it has but at least it has put my mind at rest getting to the cause of the issue. Not too sure if it is possible to get it repaired or even economically viable to do so. I would like to replace it with a DVB--S2 Sat PCI card (no room for a PCIe). Any suggestions for one that will work easily?

Just moved my dish to 19.2 E, created a new tvh docker and I am getting the same failure with no data found linuxDVB unable to provide UNC value. I first tried with default latest 4.3~. I deleted that one plus config folder. Created a fresh docker but set it as 4.2. Still failed. The only option I have now is to take my card out and see if it works on windows to rule out a hardware fault. Will do that tomorrow.

Forgot to add this image

After forcing update to get the very latest to test that, I added :6be300c4-ls25 to downgrade to the version used before 26.7.19 update, but still didn't work on either of them. Just removed tag to get back to normal latest. Don't understand how it all worked fine before. Always been using latest branch 4.3 and never used 4.2 on this docker. More net searching I think it might have something to do with drivers for my pci Skystar HD2 causing not to tune but I found these problems from about 10 years ago and seem fixed now but is was something related to mantis driver and s2 problems. I thought the Skystar HD2 was one of the best ones for out of the box compatibility because all I found was no firmware needed and supported by stock linux kernel. An attempted scan at a populated mux seems to tune then fails with error no data found and linuxdvb unable to find UNC value. So the problem seems to lie here. Is this linxdvb part of the container or part of the plugin ? All things driver related will be contained in this plugin rather than the tvh docker and that has not changed in the time of this working then not working. lspci -v gives: 04:01.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] (rev 01) Subsystem: Device 1ae4:0003 Flags: bus master, medium devsel, latency 32, IRQ 16 Memory at f0300000 (32-bit, prefetchable) Kernel driver in use: Mantis Kernel modules: mantis I have looked at various logs on my server and can't really see anything wrong. My current set up has a motorised dish with quad LNB (2 upstairs, 2 downstairs) but rarely move it from 28.2E nowadays. The motor (LNB1) is powered only by a Technomate (SD) box which I only really use if I want to watch another satellite (it only does a now/next epg if you're lucky). I have a PC LibreElec box (LNB2 - pcie DVBSky S950 ) for my main freesat viewing (HD capable) giving me a full epg, which I would turn off if moving dish. My back bedroom is where my main PC and Unraid server are with LNB3 - basically provides a second tuner for me for recordings. LNB4 is in another bedroom not used at moment (which is why I had a a spare Sat card, pcie TBS 6922SE). I keep it simple for any PC cards with just universal LNB setting as they will only see the position currently set by motorised box so there is no diseq to mess with. I am thinking about adding another tvh docker but pointing at another satellite (19.2E) as a test. Obviously anything designed to run on 28.2E only will be closed down. I had originally thought about setting multiple satellites in one docker but don't want to over complicate things, particularly with epg scans and the fact only the Technomate can do the motor. In the past I always ran DVBviewer and its Service on my windows PC. I used to add all satellites and tune individually after moving the dish and could play back from whatever Sat I was on. But I was suffering a lot of discontinuities at times on freesat and decided to try a linux based setup (LibreElec) which seemed to work better than windows drivers. After I found that to work well my next step was moving my card into Unraid instead of using it on windows/dvbviewer and it has been great until last weekend. Probably been running this plugin and docker combo for the best part of a year with no problems.

Everything was working fine up to last weekend and from Sunday not working. The only thing updated in that time was the docker to the 26.7.19 version. I noticed there was a later version (31.7.19 I think) so I forced updated to that and still not working. So then I tried downgrading to the last version prior to the 26.7 update and still not working so reverted back to the latest.

Using Linuxserver.IO TvHeadend docker after Linuxserver.IO DVB installed libreelec 6.7.2 version over OS unraid 6.7.2. Maybe just confused about the thread to post in.

I have had this docker running perfectly running Libreelec with a Skystar HD2 - until this week. I noticed my recordings had been failing since the weekend and when I tried to play a channel (via browser into a media player) that failed 'file doesn't exist'. Scanning a mux fails with no data found. The only thing I could think was the docker got updated at the weekend and so I thought maybe if I rolled back to a previous version it would work again - no luck, so reverted to latest Libreelec 4.3..something. To check there was no problem with the cable, on my main windows 7 PC I put in my spare (TBS pcie) card, installed the drivers and dvbviewer and that scanned all muxes and played channels fine. So there is not a problem with cable or LNB. So that leaves either the Skystar HD2 pci card as failed somewhere, somehow or something on the software side. When trying to scan a mux it tunes to the frequency but fails to receive any data. I decided to shut down unraid and cold boot to see if that would solve anything This is what I get on the latest scan (the main channel 4 mux): 2019-08-01 17:11:07.172 mpegts: 10714.25H in 28.2E - tuning on STB0899 Multistandard #0 : DVB-S #0 2019-08-01 17:11:07.330 subscription: 0001: "scan" subscribing to mux "10714.25H", weight: 6, adapter: "STB0899 Multistandard #0 : DVB-S #0", network: "28.2E", service: "Raw PID Subscription" 2019-08-01 17:11:17.266 mpegts: 10714.25H in 28.2E - scan no data, failed 2019-08-01 17:11:17.266 subscription: 0001: "scan" unsubscribing Before the fresh boot that I was also getting a 'linuxDVB unable to provide UNC value' when doing the scans. I'm not sure how to debug this (settings to make, where to save log file) so see if that could shed any light. Strange to me this has just suddenly stopped working after being perfect since I first set it up. The only next step I can do (tomorrow) would be to take this card out and put it in another old PC (running windows 10 though) and do the same dvbviewer test to rule out hardware failure (as long as there is no compatibility problems with W10). Any thoughts anyone please? Spent all day trying to research and figure it out but I am very limited in Linux knowledge. Maybe I could add an alternative docker to try and see if that fails. Any suggestion what to try?

After much searching and reading, as others have had similar questions, I have come to the conclusion that the SATA5/6 ports must be disabled when using the m.2 slot. The wording used in all the literature though is ambiguous because it really only mentions sharing rather than disabling. You would think it an easy thing to do to correctly write manuals with this important information.

OK thanks for the reply. I'm not quite convinced yet though. It is just the wording of sharing bandwidth that is confusing when it does not specifically state that it is an either/or situation. So even in PCIe mode you think it has to disable the SATA 5/6? So it not would really be using a dedicated PCIe lane but 2xSATA lanes instead if that is the case. So I don't really understand how it can be called a PCIe mode if is really a double SATA mode. The motherboard manual mentions in bios that for the M2 slot you set a priority bandwidth to either M2 socket 3 or the SATA 5/6 interface. This is the reason I am thinking they are shared rather than disabled. On auto the system detects the first priority device PCie M2 > SATA mode M2 > SATA devices. So if it is the case that nothing is disabled, just shared, there would not be a problem for me to have both the M2 slot and SATA 5/6 occupied.