Hey folks, sorry for the long silence, my little corner of the world has been keeping me busier than ever. I've kept on hacking on Pandafe here and there but haven't had the bandwidth for releases or support (or, indeed, reading posts/PMs). I will upload a new release once I can work through my current TODO list of known bugs and such. Its mainly bug fixes and polish, with a few new features like input configuration and custom (non-pnd) programs. Hopefully I will be able to carve out more tinkering time after that to work on further wishlist items and such, but well...yeah.
@nuhrin: Would appreciate if PanMAME and C4A MAME would be added as programs for handling the arcade type ROMs within Pandafe.
Added to my TODO list.
I found a rather nasty bug: looks like Pandafe is choking while loading the list of Pandora games. Its memory use grows and grows until it runs out and crashes.
I have installed a huge amount of Pandora games, so it's probably just one particular game that is causing this misbehavior (maybe something wrong with its PXML which causes a Pandafe bug to get triggered). It's pretty impossible to find out which one though since there is no useful information in /tmp/pndout.
Could you perhaps make the scanning more verbose, so it writes to /tmp/pndout which file it is going to scan? That way I can hopefully identify the bug-triggering PND so you have something to reproduce the bug with.
This is a critical bug because it makes Pandafe impossible to use.
Hrm. So first off, the "no useful information in /tmp/pndout" is due to a
real old commit which started running pandafe via screen as a "temporary" workaround (see the commit for details if interested). Trouble is that workaround simply swallows all stdout/stderr output, so there is _really_ no useful information. I'll fix this in the upcoming release, but for now you can:
* mount pandafe.pnd manually
* run bin/pandafe from /mnt/utmp/pandafe
* observe the hopefully useful details on the crash (and events leading up to it)
If the issue is indeed triggered by a single specific PND, as porg proposes, the easiest way to track it down is probably to do a manual binary search: remove every thing, test, add half back, test, add half of remainder back, test, etc. If you can track down a specific issue this way (and/or via error output) I'll be sure to (try to) fix it in the next release.
If the issue is actually just due to memory leaks and/or design flaws when dealing with a large number of PNDs:
* might be already fixed in my local branch (leaks plugged, etc)
* if you tar/zip/etc all your pnds into a file and PM me a link somewhere to it, I will test released and unreleased versions with that on a fresh sd card