I’d recommend TVHeadend. It’s a simple installation of two addons, the first being the server and the other being the client.
You’ll find the server addon and the client addon in the LibreELEC repository >Services>TVHeadend Server 4.3(Alpha) and the client on >PVR clients>TVHeadend HTSP Client.
Once the server addon is installed you can configure it remotely with the aid of the TVH Wizard. Very simple indeed.
To rule out any SW issues, I also imaged a new SD card with the latest 11.0.3 and the same result (no video out at all)
Here is the pastekodi from this setup = http://ix.io/4Mqj
ANy help much appreciated
Have you tried an alternative RPI3 power supply. It may be failing giving you intermittent problems.
You really need to report your YT addon issues to the addon maintainer. Remember YT is monetised via commercial ads and they don’t want anything out there that bypasses this. Hence the regular issues with the YT addon
And still there is a bit of a difference in marketshares between desktop OS, Microsoft 72% and Linux less than 3%, just face it, most people isnt ready for Linux in their daily routines, most of what they do is done with Windows.
Remember the critique, lies, damn lies and statistics. Why do so many people here want to use LE I wonder 😂
You're right: ntfsfix is severly limited. It always has been. In fact, the manpage specifically states that "ntfsfix is NOT a Linux version of chkdsk. It only repairs some fundamental NTFS inconsistencies, resets the NTFS journal file and schedules an NTFS consistency check for the first boot into Windows."
However, the issue under discussion here is that a simple unclean dismount (i.e. pulling the plug on an USB device without first dismounting it cleanly, having a power failure or other crash, or simply moving a cable with a dodgy plug or connector) will leave the "dirty bit" set on the NTFS partition regardless of whether or not anything has been corrupted. LE then refuses to remount it, ever.
As of LE11.0.3 there's no ntfsfix at all included to reset the dirty bit. That means that as soon as you have even the slightest hiccup with and NTFS disk on LE, you need to plug the HD into either a Linux box that has ntfsfix on it, or into a Windows box and run Chkdsk. That's a bit hard to live with, and simply restoring ntfsfix to LE will go a long way to fixing that problem.
If you have real NTFS corruption problems, no amount of ntfsfix will help you and only running Chkdsk on a Windows box will sort it out. But that's a Linux issue, not an LE issue. NTFS support for Linux has never been great (although these days it's sufficient for all regular purposes) but the lack of a proper Chkdsk alternative that can repair a corrupted NTFS has been a problem since NTFS support was first introduced in Linux.
As petediscrete already suggested above, testdisk may be a better alternative for ntfsfix. However, for daily LE use ntfsfix will be sufficient in most cases and infinitely better than nothing at all (which LE11.0.3 currently has).
Or else keep NTFS systems away from the Linux party. It really is a matter of re education for Windows users. With shares and other network solutions does anyone really need to be using an NTFS disc on LE anyone. And for those who do, with storage being so cheap these days a simple copy over of the contents of the NTFS disk to EXT4 would suffice before hooking up to the LE machine. Honestly what can’t be done in Linux that can be done in Windows. I prefer spending my time “consuming” my media instead of watching LE consuming my NTFS file system 😂
Not exactly a GPU card; I'm running the iGPU of the Intel(R) Core(TM) i3-7100U CPU using the Generic download. I'm really reluctant to do try a nightly because I have so many things running on this machine, docker apps etc etc that I'm afraid will break.
Can you install Kodi on your machine as a test and compare behaviour between the two.
Display Morechewitt :
OK. I've put the test image through its paces. TL;DR version: no effect. Details below.
First I replicated the issue on the LE11.0.3 image that I've been running for the past two weeks or so. The harddisk I'm using is a Seagate 8TB Archive SMR in external enclosure with USB3 interface (which also contains a 2-port USB3 hub). Partitions: 134MB FAT ("Microsoft reserved" rubbish that I never got around to eradicating) and the rest is NTFS.After a clean reboot with a previously cleanly unmounted harddisk all is well. Then I arranged for an unclean dismount of the USB harddisk. <yank>
Relevant output of dmesg:
Code[ 271.328729] usb 2-2: USB disconnect, device number 2 [ 271.328762] usb 2-2.1: USB disconnect, device number 3 [ 271.330130] device offline error, dev sda, sector 264208 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 2 [ 271.330162] Buffer I/O error on dev sda2, logical block 2, lost async page write [ 271.330198] device offline error, dev sda, sector 6555648 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 2 [ 271.330217] Buffer I/O error on dev sda2, logical block 786432, lost async page write [ 271.434126] device offline error, dev sda, sector 2048 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [ 271.434170] FAT-fs (sda1): unable to read boot sector to mark fs as dirty [ 271.480504] ntfs3: sda2: failed to read volume at offset 0x2c000 [ 271.480605] ntfs3: sda2: failed to read volume at offset 0x2c000 [ 271.491154] usb 1-1.2: USB disconnect, device number 3 [ 271.505444] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 271.705407] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=0x07 driverbyte=DRIVER_OKReplugging the harddisk replicated the issue that started this whole thread: the NTFS partition is not visible from within Kodi.
Relevant output of dmesg:Code[ 334.811535] sd 1:0:0:0: [sdb] Spinning up disk... [ 335.717672] usb 1-1.2-port2: Cannot enable. Maybe the USB cable is bad? [ 335.830629] ..............ready [ 349.005423] sd 1:0:0:0: [sdb] 15628053167 512-byte logical blocks: (8.00 TB/7.28 TiB) [ 349.048933] sd 1:0:0:0: [sdb] Write Protect is off [ 349.048950] sd 1:0:0:0: [sdb] Mode Sense: 4f 00 00 00 [ 349.049218] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 349.049656] sd 1:0:0:0: [sdb] Preferred minimum I/O size 512 bytes [ 349.049664] sd 1:0:0:0: [sdb] Optimal transfer size 33553920 bytes [ 349.110372] sdb: sdb1 sdb2 [ 349.110747] sd 1:0:0:0: [sdb] Attached SCSI disk [ 349.356826] FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. [ 349.448779] ntfs3: sdb2: volume is dirty and "force" flag is not set!Last two lines of mount output:
Code/dev/sda2 on /var/media/Seagate_8TB type ntfs3(rw,relatime,uid=0,gid=0,fmask=37777600133,iocharset=utf8) /dev/sdb1 on /var/media/FAT_134MB type vfat (rw,nosuid,nodev,noexec,noatime,fmask=0133,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)However, while mount shows the partition as mounted, it is not visible from within Kodi and /var/media/Seagate_8TB/ is empty.
Unplugging and replugging the USB drive (which seems the first option a non-technical user would think of) doesn't fix the problem, however the mount command now doesn't show /dev/sda2 at all.So let's run fsck /dev/sda2:
Codefsck from util-linux 2.38.1Which is profoundly unhelpful and doesn't fix anything. So that's the problem reproduced with the standard 11.0.3 distribution image.
Then I did the same with the LibreELEC (chewitt): 11.80.0 (RPi4.aarch64) image as per the download link above. This shows one (and only one) difference with the LE11.0.3 distro image, which is the output of the fsck command:
Codefsck from util-linux 2.39.2Finally I plugged the USB harddisk into my Ubuntu 18.04 laptop. (Yes, I know, I'm way overdue for upgrading. Deal with it.
) This system runs kernel version 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux.
Strangely enough, the NTFS partition mounted fine. I unmounted it and ran fsck /dev/sdb2 on it:
Codefsck from util-linux 2.31.1 Mounting volume... OK Processing of $MFT and $MFTMirr completed successfully. Checking the alternate boot sector... OK NTFS volume version is 3.1. NTFS partition /dev/sdb2 was processed successfully.I'm not sure why fsck on the old Linux box doesn't see the need to repair anything; on previous fsck runs on that partition it did come up with several messages of issues that were corrected. I wish I'd saved them at the time, but of course I didn't.
Cleanly dismounting the USB disk from the Linux laptop did not make any difference on the LE side: when I plug it back in I still get the "volume is dirty" error in the dmesg output.
So in summary:
- LE is more critical when it comes to refusing to mount a "dirty" NTFS partition, and
- The fsck from util-linux 2..31.1 gives more output and seems to do more than the ones in both the distro and the test LE images that I've tried.
- The fsck included in LE11 distro and the test image both don't seem to do much more than print its version number when applied to an NTFS partition.
Item 1 could be kernel-related. 6.1.58 vs. 4.15.0 is not exactly trivial, although I wouldn't be able to explain why recent kernels would be less tolerant to NTFS issues...
It took plugging the HD into a Windows box and running chkdsk on it before LE would play ball with it again. Interestingly, chkdsk found no errors! But it still caused LE to mount the NTFS partition again. Uh-huh.
I've had NTFS issues on the Linux box after a mid-write unclean dismount (files and directories that I couldn't read, write or delete anymore from Linux) and that needed a Windows box to fix. But the partition would still mount. LE seems much more picky.And that's it from me for today. Stay tuned - film at eleven...
Connect up the damaged disk to your Ubuntu laptop and try running Test Disk. You’ll get a far better insight into what exactly is going on.
Check your audio settings in the Kodi Settings. What ones are showing as available. Swap between them and see what happens.
Interesting. Had I known about this, I wouldn't have bought the 128GB, but then again they were very cheap haha. Guess I'll try to snag a 32GB one. But this shouldn't interfere with playback should it? I mean I had this issue on I believe an 8GB or 16GB SD card too.
Who knows but it really does pay to do a search first. So many posting these days without doing one first.
Might be worth a read RE: PINE64 RockPro64 4GB RAM & LibreELEC-RK3399.arm-8.90.014
Try searching on the subject of 128gb. I believe others were experiencing similar problems
Display Morethanks, posting random links does not help.
I am rather sure it's not about power.
I tried two different self powered hubs.
I use the original raspberry power supply and the USB device uses less than 200 mA / less than 1 Watt when in use. (the rest went to USB hub and power supply, because I measured the brut amount)
problem does not happen on PC.
But it's ok. I give up.
They weren’t random links. They were pointers to your error code which I assume you didn’t see the relevance in. Don’t worry I won’t be doing that again 😠
I’ve no idea how you are carrying out those measurements or what metrics you applied. It all appears quite arbitrary.
The fact that the problem doesn’t appear on a PC would indicate a power issue on the board. Btw you didn’t include a full log which is normally required before anyone even looks at your issue.
It might be worthwhile reinstalling LE at this stage. Sounds like some form of corruption on your system. Take note of your list of add ons currently installed and install them one by one checking performance of each on a fresh installation.
The only thing I could suggest here is, if you haven’t already tried this and purely for testing purposes, install an older version of LE and do side by side testing.
Before turning on the PC turn on the Bose , take it out of standby, plug in the Bose USB cable and turn on the PC and check the audio settings in LE.
What exactly is your hardware setup.
It works now. Thank you very much to all of you.
maybe it was because of USB power setting...
Maybe it conflicted with other USB devices, namely the MELE F1 Remote. (I had accidentally two plugged in)
You’ve very little power overhead available with the stick plugged in. You may experience problems again. Keep as little other devices plugged into the RPI as possible. Again consider a powered USB hub if it does.
I’m using my Bose Companion 5 on Raspberry Pi3b+ with LE11 and LE12. Just plug it in to the USB port and it shows up straight away in the Settings>Audio section.
