Notices

Nothing much seemed to happen for the --session monitor, besides the error messages that happened immediately. I was running both of these from an ssh session started on my laptop for easier cut and paste, if that makes a difference.

This thread also talks about the D-Bus message. I still can't think of what the culprit might be.

Please try the following: Start gPodder _without_ the "--maemo" switch from an xterm (or via ssh), i.e.:

This will not load all the Maemo-specific code tweaks (and it will look ugly, because it's not the Hildonized UI). When this gPodder is running, try to slide the keyboard open and see if it crashes. If it doesn't, we know that the problem is with the maemo-specific code

After closing this Non-Hildonized gPodder process, you can rm -rf ~/gpodder-downloads (the "gpodder-downloads" folder in your home directory) and ~/.config/gpodder (the "gpodder" folder in the hidden folder ".config" in your home directory), because they are only relevant for the Desktop version and will be created when running gPodder like above (without the --maemo switch).

Pleas try that and tell me if this makes any difference when sliding out the keyboard.

I ran 'gpodder --verbose' from my n810 xterm and it did not crash when I slid the keyboard in and out. I then reran it the normal way from my launcher and it once again crashed when sliding out the keyboard.

Thanks for testing this out. So, the area where the bug may hide has just shrinked quite a bit. I suspect the osso context being the culprit, at least that's the one thing that I haven't looked that much into recently, because it worked for me.

Do you feel comfortable with trying out changes I send to you on your tablet and see if we can isolate the bug even more, so I can have a look on how to fix that bug?

It would basically involve putting a development version (SVN checkout) on the tablet user's home directory, applying and reverting patches and testing if these fix the problem. I need an N810 user to go through that procedure, as I can't emulate the keyboard open software behaviour on my N800, I think.

Sure... tell me what to test and I'll test it. One thing before I get too deep into it... what data files should I backup so that I can restore my gpodder state when I'm done testing? That probably won't be necessary, but if I can easily revert my data files I'll feel quite comfortable playing with the configuration.

Try writing the "quick power-user instructions" first to save you some time and if something turns out to be too unclear I'll ask.

You can create a tarball of /media/mmc2/gpodder/ (the "gpodder" folder on your memory card) and extract it there to revert all settings, subscriptions, download history and downloaded episodes. If you want to save space, you can exclude the folders that look like md5 sums and you'll just backup the configuration without the episodes.


Now, here's what you should test: Read this guide to find out how to do a SVN checkout of gPodder "trunk" (the development code). You can do the checkout on your Desktop machine. Now, download this patch, go into the folder where you checked out gPodder, and run (where /path/to/.. is of course the path to where you downloaded that file, e.g. ~/Desktop/gpodder_r703_no-osso.patch).

After that, copy the whole checkout folder onto your tablet user's home folder via scp. Then, open ssh and cd into that folder you just copied to the tablet. Now run the following command:

Please note: The command is "./bin/gpodder" and not "gpodder" (because we're running it straight from the checkout folder). The "--local" part makes gPodder run from the current (checkout) folder and not from the system install, the "--maemo" port activates the Hildonized UI and other changes and "--verbose" should give you some messages. After gPodder is up and running this way, please slide open the keyboard and see if this fixes the problem. You won't be able to play back episodes in this patched SVN trunk checkout, as I've disabled all osso-related code (which I believe could be related to the crashes), and osso is needed for the remote procedure calls to the Nokia Mediaplayer.

Thanks for taking the time going through that testing procedure

Thanks for the clear instructions. Unfortunately, the patched svn version exhibits the bug. I got a "segmentation fault" message when it happened. Let me know if you have anything else you'd like me to try.

The new gpodder is awesome, but should it take 9 minutes to check for updates on 12 shows? The update checking time seems quite excessive. Is it this slow for anyone else?

I really hate to say anything critical, because the app clearly has so much work put into it, and generally speaking is AWESOME, but does it seem a little slow to anyone else? By slow I mean dog slow. 10 seconds to open, 10 second delay at least between clicking just about anything in the GUI. If I'm updating I have to let it sit there for several minutes, and the whole tablet becomes unresponsive, and if I click a couple of times it crashes. If I'm downloading I have to let it sit for at least a half-hour. (This isn't a function of bandwidth) Am I doing something wrong? Are my expectations too high for a desktop app that's been ported to such relatively slower hardware? Are substantial speed increases expected as the port progresses?

Anyway, my sincerest thanks to the developer for all their hard work and for releasing/porting a really solid app.

Drew

rbrewer123: Please apply the following patch (see above for procedure) to your SVN checkout of gPodder and retry on your N810 to see if this fixes the problem (this disables handling of hardware key presses, which might be a problem):

http://khan.thpinfo.com/~thp/tmp/gpo...ble_keys.patch



adammelancon and drdruish: We can surely increase the speed of the whole app, but it won't be tomorrow and won't be in one week, but we're slowly (hehe..) getting there. The reasons for it being so slow at times is that code has been added for some years that make even the most cruelsome, ugly RSS feed (missing or wrong information, etc..) and it takes time to let one RSS feed go through that whole chain of checks.

Another reason is that there are some GUI updates done that aren't really necessary, and this just needs optimization. It's not that the code is bad, it just needs someone to sit down for a week or two and optimize the important code paths step by step. There is a bug filed already to which you might want to add information: http://bugs.gpodder.org/show_bug.cgi?id=59.

I experience the slowness of the feed cache updates myself, and I'll have to have a look at it if I might be able to speed it up a little in cases where the feed itself hasn't changed.