Posts by zksHGItCVxPBhrEx7B9x

Done

I found the cause. After disabling everything under settings->media that I don't need (i.e. everything...) the problem is gone.

I thought I had tried that already.

I have added a music source from a samba share. When I change to a specific directory on this share, which contains 462 mp3's (each 100-200 MB in size) a popup appears, telling me that LibreElec is scanning the files for metadata. This takes around a minute, and what's more, it annoys me not just once in a lifetime (of the system) but every time I want to quickly satisfy my music addiction from one of those files.

I don't want no metadata, I am all satisfied with the file names of those files, which just takes a split second when I access the same directory from Windows 10. So I have disabled the media scan for the said smb share, but to no avail.

How can I disable all metadata/media information scanning overhead and just show the raw directory content.

Interestingly I also had many problems of comparable severity as the OP's. Even frequent crashes/hangups. Wifi refusing to connect. After restoring from a manual SD-Card backup I had made when I first installed LibreElec 9, almost all problems suddenly have disappeared, and I can also say "the whole system works perfectly now" (Amazon Music being the only exception).

I didn't do much to reach the "f*cked-up" state. Just create advancedsettings.xml with the well-known type of cache settings (because Amazon Music only plays with stutter). And I also changed these settings back and forth, to see if it's them who make problems, but to no avail. In my opinion it is not plausible that these settings caused the problems. But nonetheless the problems appeared only after several weeks of usage. So if LibreElec does not "modify itself" (I have turned automatic updates off for exactly these kinds of insecurities), it must be the hardware that has deteriorated. But why did it work then after restoring the original software state?

Maybe one crash caused filesystem corruption (thus causing all subsequent crashes?), but that is hard to believe to me. Even on Windows I have hardly ever experienced true FS corruption. And I have had *many* Windows crashes in my life...

What I did for restoring the backup, however, was using a brand-new SD card. I have the suspicion that it might have been the card. These cards sometimes get pretty hot and inside my Pi's housing this might have caused damage to the card itself (on the CPU I have a big heat sink of course). Maybe not damage in the sense of actually corrupting data, but rather something like much longer response times and such. Who knows.

Yes, a lot of speculation, but like the OP I wish that anyone is saved a little time when solving these kinds of issues.

Luckily my Fire TV Stick has no hickup problem whatsoever. It is a Raspberry Pi exclusive problem.

But I have discovered that the gaps often occur less frequently after I have restarted the WiFi at my router, which causes it to switch channels (presumably to less crowded ones?). So it seems somehow WiFi related and not related to the Raspberry Pi having insufficient performance.

But the big question is: how can there be any playback gaps when the buffer is (now even) 40 Megs big which is enough to load even pretty epic songs into memory in one go. Doesn't this mean that the buffers are not used by the Add-On at all?

Can the plugins' source code be inspected to see if it uses an audio or network buffer?

Thanks for this info, blueribb. Interesting to know that it occurs even with Amazon's hardware. That brings me to the idea of checking it with my Fire TV stick in the other room... I believe I have used it only for videos yet (but with them it worked fine).

I will report... but I'll have to wait until my wife is not sleeping there...

I am using the Amazon Music add-on and I am getting very short playback dropouts (~0.1 seconds) every few seconds (sometimes after every 10s, sometimes only after every minute or so). My Raspberry Pi with LibreElec 9 is connected to the network/internet over WiFi. With the Amazon VOD add-on I have no playback issues whatsoever, not even with 720p material, not even with the audio channels. So I suppose there is no physical bandwith issue nor a problem with DRM processing performance.

I had the same (AFAIK) dropouts when playing mp3's from my local network media server. But then I created advancedsettings.xml with the following content:

<advancedsettings>
    <cache>
        <buffermode>1</buffermode>
        <memorysize>20971520</memorysize>
        <readfactor>10</readfactor>
    </cache>
</advancedsettings>

After that the stutter went away completely at least with music from my local network. But the problem with Amazon Music remained.

It sounds exactly the same as with the local audio before. So my best guess is that Amazon Music add-on is probably just ignoring the above buffer settings. Don't know if this is possible.

Any ideas on how to solve it or how to diagnose?

Thanks in advance.

Now it works! Don't know why. I just re-enabled CEC (because I thought it might be related to the problem) and rebooted once again. And after that everything worked.

Even after disabling CEC again it still works (I'd have been surprised if not...)

Thanks for the help.

BTW, the sensor is TSOP31238, a 38kHz Sensor. I guess this has to work with MCE remotes.

Thanks for the tip. Now in hindsight I understand the MCE references in the wiki article a little better. I have programmed my Harmony One as "Microsoft Windows Media Center (EU)". But then, naively pressing some obvious buttons like Up/Down/Left/Right/OK did nothing.

Moreover I have repeated the irrecord test, and although the dots appear when I press buttons on the remote, the configuration file it writes contains all zeroes for the codes. Is "irrecord" the right tool at all for monitoring IR activity (in the new gpio-ir scenario...)?

I might also dig out my oscilloscope, but I expect nothing else to learn from this but that the sensor works (like it has done in the past when connected to an Arduino).

Is there another tool where I can check the raw codes the Pi thinks it sees coming from the IR receiver?

On my Raspberry Pi / LibreElec I have activated the kernel IR device (gpio-ir), and plugged an ir receiver module into GPIO18. I checked it with irrecord, and it's working (means: dots are showing when I press a button on any remote)! By the way, LibreElec is a great piece of work, keep it up!

What I wanna do now is configure my programmable remote to be used with LibreElec.

While I have tried to understand the material on the LibreElec wiki (Infrared Remotes [LibreELEC.wiki]), I guess I must be too dumb to understand. It is not clear to me what is specific for LIRC and how it relates to gpio-ir and what problems are real problems and what problems are only problems to people who are coming from outdated information. What I would like to avoid also is pressing buttons for several hours just to teach the Pi something that has been done before.

I imagine that it is probably possible to just do the following:

1) download a file for the remote of some arbitrary device X (which I don't necessarily own, but which is reasonably well supported by the community)

2) put the file to some folder in my LibreElec installation, and finally

3) configure my programmable remote (Logitech Harmony One for those who are interested) to use device X

Am I on the right track?