Pauses on disk based games.

lostless

@dd-indeed I'm assuming so. Haven't had an issue with the latest build.

DD-Indeed

Allright, gotta test it out today, just finished reformatting my USB stick. Decided to revert from NTSC back to the regular FAT32, because with NTSC, saving savestates on PS1 games took well over 30 seconds to save.

DD-Indeed

Okay, after updating the Retropie and the assets, the pauses vanished and everything seems to work faster and more reliably. Also, when I changed back to the FAT32 format, custom spashscreens started to work again as intended. NTSC fileformat is not good for this system, as it seems to have a sort of slow request on certain actions, meaning that the Raspberry skips the custom splashscreen loading, if the filesystem on the memory device is too slow or not responding quickly enough.

DD-Indeed

Edit: Gotta correct that previous message. The issue is still there, but it's not as frequent as it used to be. Usually driving games are the ones that does it, as they require constant loading of the map as you progress. So maybe the issue lies within that aspect.

edmaul69

@dd-indeed for psx in the retroarch core options, did you disable vibration? That might help the psx system.

DD-Indeed

@edmaul69

Disabling Vibration helps with this kind of issue ?

edmaul69

@dd-indeed Lr-pcsx-rearmed has an issue that when the game is supposed to vibrate even if your controller doesnt have vibrate it causes the game to lag. So it is worth turning it off then test.

DD-Indeed

@edmaul69

Is it enough, that it's disabled from the Retroarch menu and saved as global and game specific config config ? Because I've done that already ages ago, since I don't have rumble on these Dual Analog-controllers I have.

edmaul69

@dd-indeed in the retroarch gui did you go into quick menu, options and turn it off there?

DD-Indeed

@edmaul69

Yes I did, long time ago already.

edmaul69

@dd-indeed ok.

Peridot

I had this issue a few months ago and was able to fix it. You can clearly see the freeze in games like Silent Hill and Apocalypse where the levels are streamed in chuncks.

In my case, I was using a 1TB USB HDD so the fix that I found may not work for USB sticks. By default, USB HDDs spin down after a certain amount of seconds, so when you are running in Silent Hill and reach the point where it needs to stream the next segment of the level, the game freezes for half a second waiting for the hdd to "wake up" again.

The fix was to install a program called "hdparm". With this, I disabled the "sleep" function of the HDD completely, so it ran at 100% all the time. Never had an issue with any CD based game ever again. It was not a retroarch nor raspbian issue.

I don't know if USB sticks have a "sleep" mode, yours is probably not fast enough.

edmaul69

@peridot not sure how i missed him saying it was a usb stick when i read the post. But yeah i think i would have to agree with you.

lostless

FWI all, just installed retropie x86 and got the same pauses. So i think its a retroarch issue. I haven't seen it recently on the pi.

DD-Indeed

I think too, that the problem lies within the Retroarch system and I have a feeling, that it loads too much and too fast the data into RAM and when it needs to load again, the game freezes briefly, before it gets new data. This could be fixed with smoother constant data loading that prevents Retroarch from loading too much data into the RAM too fast, giving the way to HDD sleep. It can happen with all memory devices. Smaller older games don't have that issue, as they can be fully loaded into the RAM straight away.

DD-Indeed

Again I today withnessed it, I had my PiStation lid open, suddenly the game freezed for couple seconds and then the USB stick started to flash, indicating that it's transferring data and then the game continued. So either Retroarch puts the memory device to sleepmode too quickly or then it loads the data in too big chunks and when runs out of the data, the game freezes.

mitu

@dd-indeed said in Pauses on disk based games.:

Again I today withnessed it, I had my PiStation lid open, suddenly the game freezed for couple seconds and then the USB stick started to flash, indicating that it's transferring data and then the game continued. So either Retroarch puts the memory device to sleepmode too quickly or then it loads the data in too big chunks and when runs out of the data, the game freezes.

The sleep mode might be triggered by the OS (Linux), not Retroarch, which doesn't know what storage is beneath your file system.
If you check the os logs - via dmesg - when the pauses occur, do any error/message show up ?

DD-Indeed

@mitu said in Pauses on disk based games.:

@dd-indeed said in Pauses on disk based games.:

Again I today withnessed it, I had my PiStation lid open, suddenly the game freezed for couple seconds and then the USB stick started to flash, indicating that it's transferring data and then the game continued. So either Retroarch puts the memory device to sleepmode too quickly or then it loads the data in too big chunks and when runs out of the data, the game freezes.

The sleep mode might be triggered by the OS (Linux), not Retroarch, which doesn't know what storage is beneath your file system.
If you check the os logs - via dmesg - when the pauses occur, do any error/message show up ?

So should I open that in command promp immediately after the game has had those brief freezes ?

DD-Indeed

I started the device, started a game till the brief freezing occured and immediately after that exited and went into the command promp to apply that command you told. I didn't see any particular issues in it, except for two lines stating this:

And that is about the USB stick where I have the games. Is that something about the system not having catche enabled or something ?

mitu

@dd-indeed said in Pauses on disk based games.:

And that is about the USB stick where I have the games. Is that something about the system not having catche enabled or something ?

That message is from the system boot, when the stick is initialized first, doesn't seem to be something wrong with it.

You could try to play with the sdparm (or hdparm) command and disable the idle/power saving , but I doubt this works for the stick. The more I think it could be the USB port that's put into some sort of power saving (?), but I don't know offhand how we could check that.