Posts by Matthewlawson3

Quote from Da Flex

You have disabled buffering with buffer mode 3. A minimum of necessary data still goes into RAM. With memory size 0 you will use microSD instead of RAM. To avoid an early death of your microSD, use memory size 0 just for testing, not for permanent usage.

What's the result of your overclocking test?

Which LE version do you use for testing?

Does pastekodi show any unusual output when you get audio errors? If yes, post the link.H

Here is a link to a Pastebin of the log of the current stable version of LibreElec while watching an episode of Star Trek: Enterprise. It usually has the audio stutter toward the end of the episode (note: stutter happens on Patton, the movie, as well as on other things randomly) and it happened around 01:37:43 PM or so and stuttered ever so often through 01:41 PM. I have included that log portion here for you to look at. Could you please see what you can see? I don't know what I am looking for. So I don't know if it seems to have an error or not. This is before I force turbo. Working on that now.

Log File Paste

Quote from Da Flex

That's for parsing XML. Kodi will parse fine without that version attribute. Your choice.

Okay. Very good. I ran the debug, not for sure if it picked up anything. I must of accidentally erased the minutes in which the dropout happened by disabling and re-enabling the log. The time at which the drop out happens wasn’t there. May do it again tomorrow and post to see if you see anything.

I haven’t forced turbo yet, but it was in the config file already (see below). Looks like I just have to change the number, write out, save, and exit. Should I also adjust GPU memory?

# Set 'force_turbo=1' to disable dynamic overclocking and enable overclocking always.
force_turbo=0

Quote from Da Flex

You have disabled buffering with buffer mode 3. A minimum of necessary data still goes into RAM. With memory size 0 you will use microSD instead of RAM. To avoid an early death of your microSD, use memory size 0 just for testing, not for permanent usage.

What's the result of your overclocking test?

Which LE version do you use for testing?

Does pastekodi show any unusual output when you get audio errors? If yes, post the link.

I will get back to you on those questions. I am using the current stable version of LibreElec mostly, but also tested a recent nightly build and same problem.

Just so you know, I have also tested on Xbian and it does the same thing.

It seems to be toward the end of Star Trek: Enterprise’s 45 min episodes (most of the time, not always). If I watch one of those. Oddly enough.

Also, another question. Do I need version="1.0"> in my XML file at the top or does it matter?

Quote from Da Flex

PS: Another hint, not related to config.txt. /storage/.kodi/userdata/advancedsettings.xml should look like this to avoid buffering:

Code

<advancedsettings version="1.0">
    <cache>
        <memorysize>0</memorysize>
        <buffermode>3</buffermode>
    </cache>
</advancedsettings>

Ok when I built my xml I didn’t add the memorysize line. Just buffermode line. Didn’t think I needed memory size. So are you saying I didn’t actually disable buffering after all?

And set memorysize to 0?

This what I put in advancedsettings.xml. Do I need the version portion in the xml?

<advancedsettings>
  <cache>
    <buffermode>3</buffermode>
  </cache>
</advancedsettings>

Quote from Da Flex

Click!

Yes, that's all you need, and it fits for your device. It's no real overclocking, the RPi just stays at max regular clock level.

Location doesn't matter, just make it the last line of config.txt.

Yes, just remove the line again. You will not lose your guarantee by using that option.

No, try overclocking first. If it doesn't work, remove overclocking and re-rip.

Thank you. This helps me.

So force turbo is a form of overclocking, but not going all the way with voltage changes, etc? So I don't lose my warranty?

And I suppose if I don't want to force turbo 1 I can just add a # to that line in the config file and it will ignore my force turbo additional line?

Quote from Da Flex

It's worth to try. I would add force_turbo=1 to config.txt. The SoC's clock frequency will stay constantly at max then. So if it's a SoC frequency issue while playing video (speed down -> speed up...), this should fix it.

Re-ripping is also a good idea.

Some questions:

1. Where is the config.txt located?

2. You're just saying add force_turbo=1, nothing else? Am I overclocking? What would you recommend for the settings for RPI 4B 8 GB RAM?

3. Where do I add this in the txt file?

4. Can this be undone?

5. Should I re-rip first?

I also may try Re-ripping. I use MAKEMKV for all my Blu-Ray rips. May check for an update then Re-ripping.

I found an old post that said...

The fix I used was to increase the minimum clock frequency for both the ARM and the GPU by adding entries in config.txt

What do you think of this?

Quote from Da Flex

I think your microSD is fine, otherwise you would find errors at kodi.log. You can play with cache settings at advancedsettings.xml. Maybe it's just a buffer overflow, and buffer mode 3 (no buffer) can fix it.

On my stable build, I created an advancedsettings.xml and set buffer to 3 and stored it in /storage/.kodi/userdata. Watched a mkv and it still stuttered the audio eventually and looked like a quick video stutter as well during some of those audio drops.

I should note the original audio track of these MKVs tend to be DTS HD Master. Though the stable build uses regular DTS of course.

Don't know what else to do. May watch some of the stuttering videos on another computer to make sure it is not bad rips.

Quote from gedakc

My suggestion is to try a USB flash drive (either USB 2.0 or USB 3.0 - both are fast enough for HD video) in order to eliminate any potential problem associated with USB to SATA converters.

Of course feel to try all of the above since you are trying to troubleshoot an issue.

I transferred a TV show episode mkv file over to a Samsung Bar Plus USB 3.0 flash drive and connected it to the USB 3.0 port and played the video from there on the stable LibreElec build. After about 40 minutes, there was an audio dropout/stutter. Only one, but it was there. I have had only one happen before with my JBOD enclosure with mkv files as well. Sometimes I have multiple dropouts/stutters with them. There’s no discernible pattern. They seem to happen randomly. I am using audio passthrough in all situations.

I have not edited advancedsettings.xml to stop buffering yet, as was mentioned above in this post. Also, quick question on that, do I place the XML file in the root directory or where do I put it in the LibreElec folder hierarchy?

Quote from gedakc

My suggestion is to try a USB flash drive (either USB 2.0 or USB 3.0 - both are fast enough for HD video) in order to eliminate any potential problem associated with USB to SATA converters.

Of course feel to try all of the above since you are trying to troubleshoot an issue.

Okay. Will try that.

Do you think increasing the amount of memory used by Kodi could help?

Quote from gedakc

You might try copying one of the shows to a USB flash drive and then play the show from there to see if it works properly. The reason to try that is to eliminate the JBOD enclosure as a part of the problem.

If I recall correctly, there were issues with some USB/SATA converters and slow speeds with the RPi4.

See If you have a Raspberry Pi 4 and are getting bad speeds transferring data to/from USB3.0 SSDs, read this.

Okay. Are you saying copy it to a USB 3.0 flash drive or USB 2.0 drive? Does it need to be a flash drive or can it be any drive? And once it is copied do you want me to access and watch the mkv file on the PI from the flash drive? Just for clarification.

Should I also try to plug the enclosure into a USB 2.0 port instead of 3.0 to see if that fixes the issue? The enclosure is 3.0.

I also plan on trying no buffer in advancedsettings.xml when I get the chance.

Update- Audio Stuttering/drop out still exists on the nightly on my Raspberry Pi 4B. The settings are default except I enabled audio passthrough with all audio formats in that area to send to my Onkyo receiver.

Any settings I can try to change on the nightly to see if it fixes it?

Quote from Da Flex

Look on top of my link for details. Login by SSH and create advancedsettings.xml by using the nano editor, which is part of LE.

Okay. I got the nightly installed and I am setting it up with my media. I will test it tonight and let you know. So far no problems.

So I need to create an XML file called advancedsettings.xml then add the lines or just my required buffer line in your link to the file then save...correct? What is the directory the XML file needs to be go into?

I'll backup my card just in case I screw up.

Quote from Da Flex

I think your microSD is fine, otherwise you would find errors at kodi.log. You can play with cache settings at advancedsettings.xml. Maybe it's just a buffer overflow, and buffer mode 3 (no buffer) can fix it.

I would be willing to take a look at modifying cache settings. You'll have to tell me how to get to it. Do I need to SSH AND Terminal to get to it or can I do it in the settings? Or can I connect via Samba and modify the file on Windows? How do I then change the mode?

Also, I can't seem to get the nightly to load. I downloaded and unzipped with 7 zip the GZ file and used the LIBREELC installer to format and write and it didn't boot the card up. No image except for the lack of signal from the PI. Then I switched cards and tried to format using SDFormatter and then WIN32DISKIMAGER to write the .img file to the card. Same problem.

Do I need to try another nightly? I used the LibreELEC-H3.arm-9.80-nightly-20210207-91cf0cd-orangepi-plus2e.img nightly.

Sorry didn't download the right nightly. Didn't pick RPI 4. Got in now.

Quote from Da Flex

You can use default settings for the nightly.

Test your JBOD drive with the same USB cable on a desktop PC to rule out speed issues. The JBOD hard drive could be too slow for some A/V codecs (compare data rates of USB 3.0 and A/V codec).

I've had this JBOD drive enclosure hooked up to a home theater PC for years playing MKVs with no problems. Just hooked it to the PI a few days ago. Therefore, I don't believe it is the drives. The drives are in ExFat format, but like I said I just watched several things last night and today with no stutter. Stutter just started again recently today

Could it be I have a bad installation on the SD Card?

I am getting ready to boot up the latest 02/07/21 nightly, is there anything I need to set or should I just go with the default settings?

Update on the stable build. I have not so far had an audio stutter/drop out since switching to the other USB 3.0 port. I may or may not have had a half a second or less sluggish moment in the video, but it is really hard to tell for sure. Fingers crossed that the audio stutter will not reappear.

Update 2:- And as soon as I wrote this audio stutter and slight video stutter at the same time reappeared in the next movie I just resumed. Right when I started watching it.

For reference, I have hardware acceleration on, subtitles off, video interlacing off, adjust display refresh rate set to always, sync playback to display off, audio output configuration optimized. I am also using a bluetooth remote. Though I wouldn't think that would cause an issue.

I decided to try to switch the USB 3.0 port I was using to the other USB 3.0 port. When I did this and powered up the PI and played two different videos, both MKV files, both were extremely slow with audio ahead of the video. When I re-enabled hardware acceleration it was back to normal. Odd.

I have left it in that port for the moment.