porg
commented
9 years ago The definition file seems to be here: pandafe/data/Program/pcsx_rearmed.notaz
Open porg opened 9 years ago
porg
commented
9 years ago The definition file seems to be here: pandafe/data/Program/pcsx_rearmed.notaz
porg
commented
9 years ago Sorry, false alarm! Solved the issue myself.
PCSX ReARMed uses this file naming scheme: pcsx_rearmed_r
Thus Pandafe's PND cache has been outdated, and thus found no PND at the old given filepath. After issuing "Scan PNDs" Playstation ROMS launch fine again with PCSX ReARMed.
But this report was not for nothing, it made us aware of one issue. Maybe Pandafe can be expanded by a routine, which, if a program definition does not launch a PND at a given filepath, tries a rescan for that particular PND, considering both a volume name change or a file name change (i.e. version number).
nuhrin
commented
9 years ago Thanks porg, sorry for the further delay in getting out the new release I promised. There are major structural changes to the codebase, so I haven't wanted to do a wip release before I can find the time to test and polish, considering I might not be able to fix regressions found by folks right away. Still working in on it on a regular basis though, in the little bit here and there I have.
Anyway, your suggestion is an interesting one. I will add this to my TODO file to investigate. I'm not sure that your proposal will be feasible, but at the least I should be able to app some improved validation logic to app running and suggest running a pnd scan to the user if appropriate.
I have also considered:
porg
commented
9 years ago 1) auto running a pnd scan on startup if the cache is older than N days (1? 7?)
A scan can take a good minute or longer. In itself an unacceptable hold for a launcher app, which has a transient posture.
In addition to this the optimal N value is hard to evaluate. There may be occassional users, who gamble only every few weeks as opposed to daily multiple gamers/updaters for whom 7 days with a partially failing launcher means a period of unacceptable long frustration.
One could attempt to define every
All in all, a cronjob is not the right thing!
If at all automatic, the PND rescanning method shall be rather triggered by an external event or an encountered error. It shall be pushed rather than pulling. At best would be libpnd (aware of manual (web browser) and app-assisted downloads (PNDManager) plus PND additions to the filesystem (SD card)) notifying Pandafe directly via API / application bus / etc or at least via a checksummed/timestamped index, which makes clear wether a rescan is necessary or not. Not reinventing a process, if there is an intended central system process, with this duty anyhow. Dunno if it's feasible.
2) checking the pnd cache on startup (perhaps every N days also) for and running a scan if some pnds in the cache are no longer present
Good idea. Possibly libpnd provides at least some of the necessary info.
3) running a pnd scan when attempting to use a pnd that no longer exists (but is present in the cache)
Excellent, as this is truly "on demand".
4) Last but not least: Mention the necessity of a manual rescan as a potential trouble solver for "Failed to change to directory 'mnt/utmp/ …" in the instructions and FAQs! (Help menu/files, repo, forum) for creating awareness and/or Google troubleshooting. Until the supporting methods are implemented, and as a supplement, because vary users are also a benefit, especially for edge cases, which the algorithm does not catch.
porg
commented
9 years ago Even if the scan would happen in the background and the GUI still being responsive, it would be suboptimal, as you navigate through potentially outdated items, if launched would trigger the aforementioned errors. Unlikely, as per probability only a subset is outdated, but still.
We also would need to find a comprehensible pattern (animation for dis/appearing items, modal dialogue, notification, …) of how to update live content while the user browses through it.
Thus I prefer the on demand methods (user-conscious PND removal/addition at the same time or only few moments ago or encountered error).
porg
commented
1 year ago app-id → id may change in the course of this./your-sd-card/pandora/appdata/pandafe/Program/pcsx_rearmed.notaz does not use a rigid app-id-type: exact but rather uses app-id-type: prefix which continues to match also when pnd_id → id changes from pcsx_rearmed.notaz.r22 to pcsx_rearmed.notaz.r23./your-sd-card/pandora/appdata/pandafe/pnd_cache which is used both for launching standalone PNDs (standalone games) and emulator PNDs (which launch a ROM with it).Be sure that you have no ._ prefixed files (AppleDouble files) in /your-sd-card/pandora/appdata/pandafe/Program/ directory!
Scrub your SD card from invisible Apple metadata files.
At least in that directory.
find /Volumes/your-sd-card-name/pandora/appdata/pandafe/Program/ -name '.DS_Store' -print -exec rm {} \; -or -name '._*' -print -exec rm {} \;Or better on your whole SD card.
find /Volumes/your-sd-card-name/ -name '.DS_Store' -print -exec rm {} \; -or -name '._*' -print -exec rm {} \;As soon as bug #41 is fixed, step nr. 3 won't be necessary anymore.
I've upgraded my Pandora OS to 1.71 (from 1.60) and PCSX ReARMed to r21 (from r18 AFAIR) after a long time of not upgrading. Pandafe still is current, being 0.3.0.2-b464.
When trying to launch a Playstation ROM with the default associated program PCSX ReARMed, Pandafe throughs this error:
Failed to change to directory 'mnt/utmp/pcsx_rearmed' (No such file or directory)Launching PCSX ReARMed on its own and loading the ROM from its menu, works fine. So either the PND-structure of PCSX ReARMed changed and Pandafe's program definition (=syntax) is not up to date anymore (the error message makes me rather guess this), or PCSX's argument-name for the rom-path changed?