Posts by LybsterKodi

HiassofT

"LE has no knowledge about the used kodi in an update "

I'm surprised but OK

"If something goes wrong with a nightly then restore your backup"

Simply restoring the backup means that the newly installed nightly remains in place so I need to do a clean install and then restore the backup. Earlier on (several months ago) I did try cloning the SSD to an HDD but whilst both were 120GB devices they wern't identical and even though I used clonezilla and told it to ignore the size difference (loads of empty space mainly) the clone would not work. If there's a better way I'd be grateful for being instructed.

"or stick to official release builds."

I would have done if they'd worked. I'm using the nightlies because they have fixed many of the problems I'd been having.

chewitt

I know - I was in IT for a long time at both developer and manager level and I've seen some major bloodshed.

On a totally unrelated subject I did look at the SD burner and QT, I spoke to several people I'm still in touch with in the development community - the general feeling was if it involved QT run away quickly.

Sorry, I wasn't being ultra clear. Rather than inform people partway through the update process they should be informed BEFORE it starts so that they can make a decision based on knowledge about a specific upgrade.

Part way through the process your software decides which addons are going to be permitted so the technology is there. Why not move that check to the front of the queue so the process can be aborted is desired.

I did make a backup before carrying out the upgrade. I also ran an export on the database and I'm backing that up now. When that's finished I'll try rolling back again.

I'll have a look, but I tend to watch live TV on the TV not on Kodi so I wouldn't have noticed that.

Is there some way that you can warn people that installing an upgrade from the nightlies will result in an addon being removed. I have very few addons - two skins, one visualisation and TVHEadend (version 4.2). As part of the upgrade process I was informed that TVHeadend had to be removed. I've installed 4.3 (Alpha) and that seems to work BUT I now have a lot of messing about to reconfigure everything.

Thank you for that - new keyboard now needed due to coffee spluttering!

And yes switching to matroska does seem to have fixed it.

I think this post belongs here rather than in the PVR group. Using TVHeadend (4.2) I recorded an episode of Doc Martin with stream profile of "pass". Playing it back lip sync was out and it was "stuttering" sort of freeze of a 10th of a second to give jerky movements.

I copied the .ts file to a memory stick, plugged it into one of the TVs USB ports and playback was perfect. I've recorded 3 other programs to test (different times, different channels) with the same result.

Recordings are being saved onto the SSD that Kodi runs from so to eliminate that I copied the .ts file onto the 6TB HDD I store my films on. Still stuttering on playback.

I'm guessing the issue is caused by ffmpeg so I'm going to try changing the stream profile to "matroska" and see if that helps. I'll report on that later today.

OK, I'll just disconnect once a week and hook up to Windows to check the disk - just until I'm sure things are working properly - fingers crossed

heitbaum posted the above in August. Is it still correct? I was hoping to be able to check my 6TB disk via ssh whilst it was still attached to the RPi4

I don't wish to be contentious but Windows & RPi3 LE 9.2.8 (I think) have worked fine since 2018. Switching to RPi4 & LE10 - not handling mp4 file correctly, moved to LE11 CEC problems & SAMBA problems. Or to put it another way I don't think its Windows fault.

I have FileZilla (similar to WinSCP I assume) but, unfortunately, I didn't think to try it. But a simple disk copy should be no problem especially with oodles of space left.

The 6TB disk is attached to the RPi4 by USB cable into one of the USB3 ports, the SSD holding LibreElec and Kodi is in the other. The filesystem is bog standard NTFS - again working perfectly since 2018 on the RPi3. The disk is the one that was corrupted several times but just worked happily when connected to the RPi3 for the last few weeks.

I have no idea how to investigate. If you have any suggestions I can follow I'm interested.

I'm having my latest attempt to switch to the RPi4. It seems to have gone all right (to early to really tell yet) apart from one weird phenomena. In music videos I have a (downloaded from YT) small clip from Medieval Babes. The title is Gaudete. When I tried to play it I couldn't and investigating I found the mp4 was missing (the jpg & nfo are there). When and why the mp4 isn't there I'm not sure - it is on my backup disk which was refreshed this morning whilst I was still on the RPi3 so I suspect importing the music videos did it (whatever it is).

I thought - OK I'll copy it back - which is where I get the weird message that the file is to large - we're talking about a roughly 5MB file on a 6TB disk with a couple of TB spare!

Even weirder if I change the name from Gaudete.mp4 to xxGaudete.mp4 it copies across just fine.

I don't know if any other files are missing yet - I'm off to write a small program to check everything out.

Anybody any ideas?

I've just downloaded the latest nightly, burnt a clean SSD to try things out and so far I'm impressed. I did have a slightly weird thing happen. Normally I've been plugging the boot SSD into the bottom USB3 port. This time I plugged it into the top one and a 600GB spinner (I'll swop to my 6TB after I've tested for a while) into the bottom. I was asked to choose an OS and the RPi4 was going on-line to download my selection.

Is there a specific order that the Pi looks for bootable media in and does it just stop looking as soon as it finds a drive connected OS installed or not? On the other hand is it just something weird I must have done?

heitbaum

Thanks. I guess all I can do is try things again and hope something works differently this time.

One thing I did notice is that my synchronisation program (written in Delphi and using standard windows API calls (ShFileOperation) was running at very slow speeds on copying a file from the 6TB HDD to backup eg over 2 minutes for a .nfo file. With the RPi3 the same operation takes a few seconds.

heitbaum

Thanks for that.

Before I install the latest nightly I do have one more question. My new 6TB powered Seagate Hub (2 USB ports) was corrupted 3 time whilst hooked onto the RPi4 - last time under LibreELEC-RPi4.arm-11.0-nightly-20220820-b2dced8. The same HDD is happy on my old RPi3 setup - absolutely no problems. The only thing I know would be writing to the HDD is samba.

Long preamble - my question is what are the chances that it was the incomplete implementation of samba that caused the corruption? I do know that I forgot on several occasions to access via \\server\folder and received the can't find it message.

Sorry to be a pain but does this mean that samba is now working fully and correctly? I read the github entry and cannot understand it (no surprise there) and tried googling to understand dcerpc and srvsvc - good way to waste time

petediscrete

Thanks for the suggestion. I'm skilled with Windows not with Linux (4 Windows PCs to 1 Linux one) so I would have no idea what I'd be looking for apart from the disk becoming corrupt again and spending another 12 hours copying all the files back. The 6TB HDD was connected to a USB3 port on the RPi4 (and is currently plugged into a RPi3 USB2 port), only for population was if connected to the Windows PC.

If you can expand on your suggestion I'm willing to give it a go.

The story so far for the 6TB HDD:

1. copy 4TB of files of backup

2. run Windows app (homebrew written in Delphi) to modify 6TB HDD file names and .nfo to reflect name changes

3. set up the RPi3s (LE 9.2.8, Kodi 18.9), removed sources and cleaned database

4. plugged 6TB HDD in

5. set up new sources and loaded database

6. no last played information

7. Exported database just in case nfo format was different

8. was told I'd forgotten about advanced settings.xml

9. use Windows via SAMBA to a) delete nfo files (c 7200 of them)

10. use Windwos via SAMBA to copy nfos from backup to 6TB HDD

11. removed sources, cleared databases, reset sources loaded database

12. everything fine

That pretty much confirms to me that the HDD is OK. I'm wondering if the incomplete implementation of SAMBA on the RPi4 could be responsible for the disk corruption. I can see no reason why Kodi should be writing to the sources unless I export the database and any file manipulation I do is via SAMBA so it will be writing to the disk.

Any thoughts?

I tried to connect it to the RPi4 again - not recognised. This time when I connected to my Windows PC it asked to scan and fix - FUBAR. I have for now given up on the RPi4. I do not know where the problem is but I suspect LibreElec. It may be the Pi but lack ability to test it. I'm going to swop the new 6TB HDD onto the old RPi3 system and see if it gives problems. If it does I'll apologise to LibreElec.

Any suggestions on how to test the Pi welcome.

System is setup on 128GB SSD.

Chkdsk and other disk testing utilities run on Windows PC and no problems identified.

The Seagate is set to spin down after 15 minutes same as the other Seagate 6TB HDD I had on the RPi3 setup which has run since 2018 with no problems.