Posts by frankvw

    OK. As per the advise I received here I've tried the same ROMs with RetroArch. They work, and fairly smoothly, too. No sound yet and an annoying frame counter in the top right hand side of the screen, but I'm sure that's a matter of the proper settings. (I've been tied up with work lately and haven't yet had the time to sit down for an hour or two and do that.)

    However, this now begs the question: why do these games run smoothly when I fire up PCSX ReARMed via RetroArch and not when I do the same directly from Kodi? (I believe that is RetroPlayer, am I right?) What's the difference?

    I'm not intimately familiar with the gaming architecture as it is currently implemented, so pardon my ignorance. :) Is it a matter of tweaking settings in LE or Kodi? I'd prefer to do this from LE if possible rather than having RetroArch terminate Kodi. I can live with it, of course, and if that's what it takes I'll be happy to, but I'm still curious what causes the games to run so badly through RetroPlayer, seeing as it's both PCSX ReARMed doing the actual work here?

    PS1 games are known to be very demanding on an RPi. Not sure if they run smooth on any RPi OS.

    Multi-Threading is the best way to get max. performance, but the PS1 emu has to be made for this (can be a serious task).

    See what pure gaming OS'es can do, and then compare with the LE performance.

    If you see room for improvement after this, make it a feature request.

    Multithreading would be great, but I understand how serious a job that is. That said, Mario77 has it running fine on his RPi2 so there must be something wrong with my install or settings. Any suggestion on how to debug, what to finetune and/or change would be appreciated!

    I haven't tried RetroPi because I only have one Pi and it's pretty much on 24/7 duty running Kodi. If I take it down to tinker with it for a few hours I'll have a domestic uproar on my hands. :)

    May I ask what kind of performance issues are you having with PS1 emulation?It works fine on Rpi2..

    Of course you may! :) As I already mentioned in this thread, games run slowly and jittering/halting: a half second burst of movement on the screen and audio out of the speaker, then a second of nothing. It's like you're trying to play HD video on a 1990's 386.

    If it works for you, there is obviously something I have to change and/or finetune, and all suggestions would be appreciated!

    Maybe I'm dense, but I'm also confused. :)

    When I downloaded LE 9.0.2 for the RPi3/3+ (having a RPi3 Model B myself) I noticed that the download option for this model links to libreelec-rpi2.arm-9.0.2.img.gz which, as the name suggests, has RPi2.arm as its architecture. It works fine (apart from performance issues with PS1 emulation for retro gaming) but I'm wondering if this is correct.

    Is the same distro meant for both the RPi2 en the RPi3/3+ or do I have the wrong distro? Will there be different distros in the future, perhaps one optimized for the RPi3/3+ compared to the RPi2?

    // FvW

    I just managed to get PCSX ReARMed running on my RPI3B with LE 9.0.2 with BIN/CUE images that I have made from my old PS1 ROMs (legally bought). I am able to play these games on PCSX Reloaded on my Ubuntu laptop, so the images are fine.

    On the RPi3B it works, but the Pi is obviously not oomphy enough. The games run extremly slowly and jittery with gaps in the audio, and the video is too laggy and halting to be useable. A quick look at "top" in the console reveals a total load of around 1.50 to 1.80. From that my guess is that PCSX ReARMed is not multi-threading and uses only one core.

    While I had my concerns about the Pi having enough grunt to emulate a PSx to the point where games are playable, I do wonder if there is anything I can do to enhance performance. I do not have a BIOS installed (yet, not having worked out how to do that) but I'm not sure that would solve the problem.

    So. My questions are:

    1. Is the RPi3B supposed to be able to run PCSX ReARMED to the point where it can play games like Tombraider (1, 2 and 3)?

    2. If so, what can I do to increase performance to the point where PSx emulation this becomes a usable feature? Will installing a BIOS help in this respect?

    Tnx!

    // FvW

    Hi everyone,

    There have been some questions in these forums about RTC support in LE, and there's various info on the web, some of which is confusing because it applies to Raspbian or to older versions of OE, so I thought it might not be a bad idea if I simply documented my procedure for installing a Real Time Clock in my Raspberry Pi with LibreElec 8. This worked for me, right off the bat.

    [Update, September 2024: This still applies to later LE versions, including LE12. Tested and found to be working on the RPi3 and RPi4. Note that the RPi5 has a RTC built in and that LE has support for same.]

    These instructions are for the DS3231 RTC modules that can be ordered for next to nothing from a variety of sources.

    1. Unplug your Pi and Install the RTC module onto the GPIO connector pins 1-4 as follows:

    DS3231.jpg

    2. Switch your RPi back on and SSH into it.

    3. Enable kernel support:

    3a. Remount LE system partition r/w: mount -o remount,rw /flash

    3b. Edit /flash/config.txt and add (somewhere near the end): dtoverlay=i2c-rtc,ds3231

    3c. Remount LE system partition r/o: mount -o remount,ro /flash

    3d. Reboot.

    4. Adjust the RTC's time:

    4a. Verify local system time with the 'date' command. If local time is off, either adjust it manually or connect your Pi to the Internet and wait for it to the the correct time from an NNTP server.

    4b. Transfer local time to RTC: hwclock -w

    4c. Verify RTC time: hwclock -r

    That's it. You're done. Your LibreElec RPi will now have the correct time every time it powers up. Don't worry about loading kernel modules, disabling fake clocks or other configuration changes. In LE8 you don't need them; whatever instructions you may have found referring to that sort of thing applies to other operating systems or older versions.

    Note: edits to /flash/config.txt should survive LE upgrades; edits to /flash/distroconfig.txt won't. Should you end up having to reinstall LE, don't forget to restore your edits to /flash/config.txt.

    I'm running LE with the Xonfluence skin. Since I switched ffrom OpenElec to LibreElec the "In Progress TV shows" menu button in Xonfluence hasn't worked. I have asked the author of Xonfluence (helly) what the problem might be, and with his excellent support (kudos!) it became immediately clear that the file ~/.kodi/userdata/library/video/inprogressshows.xml is missing on LE. In fact, so is the ~/.kodi/userdata/library/video subdirectory; there is nothing under ~/.kodi/userdata/library.

    I have created the "video" subdirectory under library and put helly's inprogressshows.xml file there, and now the "In progress TV shows" menubutton works. In other words, the fact that this file is not included in LE causes the "In progress TV shows" navigation button not to work.

    While in my case this problem (the missing XML file) was exposed in Xonfluence, other skins might be similarly affected.

    Contents of inprogressshows.xml:

    XML
    <?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
    <node order="4" type="filter" visible="Library.HasContent(TVShows)">
    <label>626</label>
    <icon>DefaultInProgressShows.png</icon>
    <content>tvshows</content>
    <rule field="inprogress" operator="true" />
    </node>

    I have only looked at LE8, so I'm not sure if this problem still exists in LE9. If it does, simply adding the missing subdirectory and file will fix it. :)

    typically you would use a dtoverlay as long as the rtc is supported.

    see, adding-a-real-time-clock-to-raspberry-pi.pdf

    Thank you for responding! I've seen that PDF. It says:

    Quote

    This tutorial requires a Raspberry Pi running a kernel with the RTC module and DS1307

    module included. Current Raspbian distros have this, but others may not!

    ...

    You'll also need to set up i2c on your Pi, to do so, run sudo raspi-config ...

    Hence my question. :) Does the current version of LE fit the kernel requirements and what (if anything) could I use instead of raspi-config which LE doesn't have?

    OK, so I've had to migrate from OpenElec to LibreElec because OE is now dead to the point where stuff is broken and doesn't get fixed. I was a little apprehensive, because my previous experience with LE on my RPi3 was a just a sequence of crashes which made me decide to go back to OE. But this time was different, and a simple manual update did the trick, as painlessly as advertised.

    There's just one thing: After the migration I can't get into Kodi's Samba shares any more from my XP machine. When I do a 'net view' on the XP box I get a "system error 71" Yes, I know, XP is ancient history, but for a variety of reasons (starting with the fact that I'm in Africa, using hardware so old that the serial numbers are in Roman numerals) that's what I've got.

    Is this because LE 8.2.1 runs a Samba version which won't play nicely with XP any more, or is it because XP is confused because \\Openelec\sharename is now suddenly \\Libreelec\sharename and needs some massaging before it will see the new configuration?

    I have no other machines (neither Windows nor Linux based) on my network.

    This is merely annoying and not a big disaster if it turns out to be unfixable; I can always use SFTP as a work-around. Still it would be nice if this were easily fixable (read: short of upgrading my woefully outdated XP to something less archeological). :)

    All feedback appreciated!!

    Quote

    Deinstalling the plugin should solve the crashes.

    Thank you! That helps.

    Unfortunately this was only one of the many things that cause crashes. Also, what I don't get is, how can a plug-in from the repo be that crashy on my Kodi installation? If it were that bad surely it would be either pulled, fixed or marked broken. It isn't, so I assume that this isn't common behavior for a standard plug-in from the repo, which suggests other factors being in play as well.