Active Topics
-
The N900 is now 15 years old! (9)
to Nokia N900 by Arno_11 - 11 hrs, 59 mins ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 6 days ago - more...
|
2008-09-25
, 07:58
|
|
Posts: 53 |
Thanked: 6 times |
Joined on Sep 2008
|
#152
|
Thanks a lot for this procedure, I will try and let you know when I am done though for testing purpose, it is better to download podcasts on N810 only for the moment I guess looking at my skills of manipulating files on N810.
|
|
2008-09-26
, 21:44
|
|
Posts: 6 |
Thanked: 3 times |
Joined on Aug 2008
|
#153
|
i just installed gpodder and got this error. i ran it with verbose to get more info, anyone have any idea what is causing it, it seems like i have all the sqlite stuff installed. thanks
~ $ gpodder --maemo --verbose
[ 1.673] Using ISO-8859-15 as encoding. If this
[ 1.674] is incorrect, please set your $LANG variable.
[ 2.232] (gPodderLib) Creating gPodderLib()
[ 2.492] (Config) Update: videoplayer = xdg-open
[ 2.511] (Storage) Setting up SQLite database
[ 2.596] SQLite connection for thread 1073859456 opened.
Traceback (most recent call last):
File "/usr/bin/gpodder", line 166, in <module>
sys.exit( main())
File "/usr/bin/gpodder", line 125, in main
from gpodder import console
File "/usr/lib/python2.5/site-packages/gpodder/console.py", line 21, in <module>
from gpodder import download
File "/usr/lib/python2.5/site-packages/gpodder/download.py", line 29, in <module>
from gpodder.libgpodder import gl
File "/usr/lib/python2.5/site-packages/gpodder/libgpodder.py", line 490, in <module>
gl = gPodderLib()
File "/usr/lib/python2.5/site-packages/gpodder/libgpodder.py", line 86, in __init__
not db.setup({ 'database': os.path.join(gpodder_dir, 'database.sqlite') })
File "/usr/lib/python2.5/site-packages/gpodder/dbsqlite.py", line 56, in setup
self.__check_schema()
File "/usr/lib/python2.5/site-packages/gpodder/dbsqlite.py", line 98, in __check_schema
)""")
sqlite3.OperationalError: disk I/O error
[ 64.329] (Config) Flushing settings to disk
~ $ gpodder --maemo --verbose
[ 1.673] Using ISO-8859-15 as encoding. If this
[ 1.674] is incorrect, please set your $LANG variable.
[ 2.232] (gPodderLib) Creating gPodderLib()
[ 2.492] (Config) Update: videoplayer = xdg-open
[ 2.511] (Storage) Setting up SQLite database
[ 2.596] SQLite connection for thread 1073859456 opened.
Traceback (most recent call last):
File "/usr/bin/gpodder", line 166, in <module>
sys.exit( main())
File "/usr/bin/gpodder", line 125, in main
from gpodder import console
File "/usr/lib/python2.5/site-packages/gpodder/console.py", line 21, in <module>
from gpodder import download
File "/usr/lib/python2.5/site-packages/gpodder/download.py", line 29, in <module>
from gpodder.libgpodder import gl
File "/usr/lib/python2.5/site-packages/gpodder/libgpodder.py", line 490, in <module>
gl = gPodderLib()
File "/usr/lib/python2.5/site-packages/gpodder/libgpodder.py", line 86, in __init__
not db.setup({ 'database': os.path.join(gpodder_dir, 'database.sqlite') })
File "/usr/lib/python2.5/site-packages/gpodder/dbsqlite.py", line 56, in setup
self.__check_schema()
File "/usr/lib/python2.5/site-packages/gpodder/dbsqlite.py", line 98, in __check_schema
)""")
sqlite3.OperationalError: disk I/O error
[ 64.329] (Config) Flushing settings to disk
 |
|
2008-09-27
, 09:29
|
|
Posts: 1,391 |
Thanked: 4,272 times |
Joined on Sep 2007
@ Vienna, Austria
|
#154
|
Originally Posted by greenmanspirit
Yep. It is a disk error. Have you inserted your internal SD card, and is it working correctly? Please try removing /media/mmc2/gpodder/ and start from sctatch to see if this fixes your problem.
i just installed gpodder and got this error. i ran it with verbose to get more info, anyone have any idea what is causing it, it seems like i have all the sqlite stuff installed. thanks
If not, please file a bug report over at http://bugs.gpodder.org/, because we can more easily and better handle bug reports and progress that way. Forums are not well suited for tracking and discussing bugs. Thanks for your help!
|
|
2008-09-30
, 18:49
|
|
Posts: 1,391 |
Thanked: 4,272 times |
Joined on Sep 2007
@ Vienna, Austria
|
#155
|
gPodder 0.12.3-maemo1, which fixes some UI issues with the toolbar and GTK button rendering, should be available in Maemo Extras soon (Diablo has not yet built, Chinook has been built and promoted already). This doesn't include Nick's performance changes for now (see the other thread for details).
 |
|
2008-12-06
, 01:50
|
|
Posts: 4,672 |
Thanked: 5,455 times |
Joined on Jul 2008
@ Springfield, MA, USA
|
#156
|
I see that 0.13.1 was released for the desktops some time ago, now.. but nothing's been updated in the maemo repos. I'm still at 0.13.0-1 and still dealing with all the old problems from that version that were posted to the bug tracking.
Any indication of when it'll get pushed up to the maemo repositories?
Any indication of when it'll get pushed up to the maemo repositories?
|
|
2008-12-06
, 11:37
|
|
Posts: 1,391 |
Thanked: 4,272 times |
Joined on Sep 2007
@ Vienna, Austria
|
#157
|
Originally Posted by danramos
0.14.0 will be out soon, and I'll roll a Maemo package of that then. I re-installed my Linux environment and have not gotten around to install and configure the Scratchbox/Maemo SDK environment - it's tedious work :/
I see that 0.13.1 was released for the desktops some time ago, now.. but nothing's been updated in the maemo repos. I'm still at 0.13.0-1 and still dealing with all the old problems from that version that were posted to the bug tracking.
Any indication of when it'll get pushed up to the maemo repositories?
I hope to be able to get the package prepared soon!
|
|
2008-12-07
, 23:31
|
|
Posts: 39 |
Thanked: 0 times |
Joined on Aug 2007
|
#158
|
Very interesting project. I gave up on the original gPodder port a long time ago due to the speed issues. I'm having not dissimilar issues in this newer version, but they've been brought up plenty of times earlier in the thread so the reasons are clearly known.
I'm currently using Videocenter for podcatching. It has a major bug in failing to rename some files after download, and now seems to be a dead project with no chance of being fixed. It would be fantastic to be done with it, although it did show promise for a while, and instead use a project that has clearly had some care and attention spent on it - gPodder.
I'd really like to use gPodder. It's much more geared toward audio content, but Videocenter does undeniably handle the RSS a lot faster.
I throw a lot at these applications, so seemingly have a harder time than many others writing here who seem to manage to use gPodder, something I haven't yet managed. I've imported 21 feeds. Most of them have sensible publishers that keep x number of episodes in the feed, but a few insist on retaining all episodes. One such is around the 850 show mark, another around 250. I guess these might be harder to deal with, but the new episodes seem to be at the top of the feeds. Are the whole feeds being parsed regardless of size? Do they need to be? I'm no expert on RSS. Does the mechanism use SAX or DOM style parsing? Is there a guarantee that new episodes will be at the top of feeds or could they be in any order?
Looking at the verbose output it appears that if a feed is unchanged no time is spent reviewing it, but otherwise the same processing that was required when first importing will be required again. Is this the case, because for this list of feeds that takes in excess of half an hour - perhaps longer, and i'd say maybe half of these feeds I subscribe to update daily. Videocenter takes about 5 minutes to do the same. I'm not sure how well it handles bad RSS, but it seems to manage these 21 well enough.
gPodder seems to reread some feeds that episode-wise haven't changed. I can only assume that they must have changed in some other way. Perhaps if somebody is pushing an unchanged XML file to their host every so often the change to a timestamp is enough to convince gPodder that it has changed. If that happens to be the 850 show feed, gPodder now checks each item. Even at 2-3 a second, this obviously still takes some time. Even if there is a new episode in the feed it still seems to need to read all 850 items before it can move on.
It was mentioned some further back in the thread that there was work to be done on the RSS, time permitting. Has progress been made on this? I ask from the standpoint of somebody that can't offer any help (beyond testing and suggesting I suppose) that would really like to use gPodder and get rid of Videocenter.
If anything I've said here is inaccurate then please let me know. I've only brought up so many specifics because they don't seem to have been discussed yet and they seem to be the main barrier to me being able to use gPodder successfully at the moment.
I'm currently using Videocenter for podcatching. It has a major bug in failing to rename some files after download, and now seems to be a dead project with no chance of being fixed. It would be fantastic to be done with it, although it did show promise for a while, and instead use a project that has clearly had some care and attention spent on it - gPodder.
I'd really like to use gPodder. It's much more geared toward audio content, but Videocenter does undeniably handle the RSS a lot faster.
I throw a lot at these applications, so seemingly have a harder time than many others writing here who seem to manage to use gPodder, something I haven't yet managed. I've imported 21 feeds. Most of them have sensible publishers that keep x number of episodes in the feed, but a few insist on retaining all episodes. One such is around the 850 show mark, another around 250. I guess these might be harder to deal with, but the new episodes seem to be at the top of the feeds. Are the whole feeds being parsed regardless of size? Do they need to be? I'm no expert on RSS. Does the mechanism use SAX or DOM style parsing? Is there a guarantee that new episodes will be at the top of feeds or could they be in any order?
Looking at the verbose output it appears that if a feed is unchanged no time is spent reviewing it, but otherwise the same processing that was required when first importing will be required again. Is this the case, because for this list of feeds that takes in excess of half an hour - perhaps longer, and i'd say maybe half of these feeds I subscribe to update daily. Videocenter takes about 5 minutes to do the same. I'm not sure how well it handles bad RSS, but it seems to manage these 21 well enough.
gPodder seems to reread some feeds that episode-wise haven't changed. I can only assume that they must have changed in some other way. Perhaps if somebody is pushing an unchanged XML file to their host every so often the change to a timestamp is enough to convince gPodder that it has changed. If that happens to be the 850 show feed, gPodder now checks each item. Even at 2-3 a second, this obviously still takes some time. Even if there is a new episode in the feed it still seems to need to read all 850 items before it can move on.
It was mentioned some further back in the thread that there was work to be done on the RSS, time permitting. Has progress been made on this? I ask from the standpoint of somebody that can't offer any help (beyond testing and suggesting I suppose) that would really like to use gPodder and get rid of Videocenter.
If anything I've said here is inaccurate then please let me know. I've only brought up so many specifics because they don't seem to have been discussed yet and they seem to be the main barrier to me being able to use gPodder successfully at the moment.
|
|
2008-12-08
, 09:06
|
|
Posts: 1,391 |
Thanked: 4,272 times |
Joined on Sep 2007
@ Vienna, Austria
|
#159
|
Before starting, let me say thanks for this helpful post highlighting some important performance issues 
Thanks for the kind words 
gPodder is running on Python, an interpreted language. Also, it's using Feedparser (feedparser.org) to parse its feed, which makes it (IMHO) more compatible to strange RSS/Atom feeds than other solutions. Sadly, this also means some performance impact.
One possibility would be to have a web service carry out the hard work and make gPodder only "read" the data from the webservice without any heavy lifting done. This would make things really (I mean, really, really!) fast (in terms of checking for updates), but would of course make gPodder dependent on such a web service.
Yep, changed feeds get parsed completely from start to end, and you're right - the reason for this is that the episodes can theoretically be in any order (heck, some podcasts don't even provide titles or publishing dates, which makes it really hard to present these episodes nicely in a GUI way).
To my knowledge (and by having a short peek at the source), feedparser uses SAX to parse feeds.
Oh, by the way: If you are using gPodder on your Linux Desktop, you can also download pocasts there and sync it to your Tablet. Although this is probably not what you want
gPodder relies at the "etag" and "Last-Modified" headers/features of modern web browser to detect changed files. This should work most of the time, especially for static file, but of course if the feed author is not taking care of this (e.g. the feed is generated dynamically by a script), it won't work and we have no chance of detecting this.
There have been some generic speed improvements to the database code, but no direct work at optimizing feedparser.
Have you tried the latest Maemo version (0.13.0) of gPodder yet? If so, is it just the parsing speed of feeds thare you don't like? How would you like gPodder if parsing was blazingly fast (with the added dependency on a web service)? Thanks for your feedback!
Originally Posted by onion_cfe
Yep. The performance issues are not something that inherently _are_ in gPodder, but something that can be fixed with someone sitting down a week or two and streamlining the code.
Very interesting project. I gave up on the original gPodder port a long time ago due to the speed issues. I'm having not dissimilar issues in this newer version, but they've been brought up plenty of times earlier in the thread so the reasons are clearly known.
I'm currently using Videocenter for podcatching. It has a major bug in failing to rename some files after download, and now seems to be a dead project with no chance of being fixed. It would be fantastic to be done with it, although it did show promise for a while, and instead use a project that has clearly had some care and attention spent on it - gPodder.
I'd really like to use gPodder. It's much more geared toward audio content, but Videocenter does undeniably handle the RSS a lot faster.
One possibility would be to have a web service carry out the hard work and make gPodder only "read" the data from the webservice without any heavy lifting done. This would make things really (I mean, really, really!) fast (in terms of checking for updates), but would of course make gPodder dependent on such a web service.
I throw a lot at these applications, so seemingly have a harder time than many others writing here who seem to manage to use gPodder, something I haven't yet managed. I've imported 21 feeds. Most of them have sensible publishers that keep x number of episodes in the feed, but a few insist on retaining all episodes. One such is around the 850 show mark, another around 250. I guess these might be harder to deal with, but the new episodes seem to be at the top of the feeds. Are the whole feeds being parsed regardless of size? Do they need to be? I'm no expert on RSS. Does the mechanism use SAX or DOM style parsing? Is there a guarantee that new episodes will be at the top of feeds or could they be in any order?
To my knowledge (and by having a short peek at the source), feedparser uses SAX to parse feeds.
Looking at the verbose output it appears that if a feed is unchanged no time is spent reviewing it, but otherwise the same processing that was required when first importing will be required again. Is this the case, because for this list of feeds that takes in excess of half an hour - perhaps longer, and i'd say maybe half of these feeds I subscribe to update daily. Videocenter takes about 5 minutes to do the same. I'm not sure how well it handles bad RSS, but it seems to manage these 21 well enough.
gPodder seems to reread some feeds that episode-wise haven't changed. I can only assume that they must have changed in some other way. Perhaps if somebody is pushing an unchanged XML file to their host every so often the change to a timestamp is enough to convince gPodder that it has changed. If that happens to be the 850 show feed, gPodder now checks each item. Even at 2-3 a second, this obviously still takes some time. Even if there is a new episode in the feed it still seems to need to read all 850 items before it can move on.
It was mentioned some further back in the thread that there was work to be done on the RSS, time permitting. Has progress been made on this? I ask from the standpoint of somebody that can't offer any help (beyond testing and suggesting I suppose) that would really like to use gPodder and get rid of Videocenter.
If anything I've said here is inaccurate then please let me know. I've only brought up so many specifics because they don't seem to have been discussed yet and they seem to be the main barrier to me being able to use gPodder successfully at the moment.
|
|
2008-12-09
, 23:02
|
|
Posts: 39 |
Thanked: 0 times |
Joined on Aug 2007
|
#160
|
Thanks for your detailed response. It feels good to have been drawn into being interested in new apps on the tablet again. I've been taking the thing for granted recently!
This did cross my mind yesterday also. I'd definitely try such a service for convenience, but it'd be a bit of a shame to create a single point of failure in something that's otherwise fairly distributed. Syncing with another linux box doesn't really achieve what i'd like as you suspected, since my whole goal is that the tablet does everything. I am playing with the desktop version too though to get a feel for it's speed. Even that sat on the 850 item feed for a few minutes, so I think a lot of this is harsh reality on the imperfections of RSS rather than differences in processing speeds, of course not discounting that entirely.
I definitely like the look and feel of the application. Ironically when I first tried to use it in verbose mode I missed off the maemo flag and launched it with the normal interface and thought it fitted quite well. If there's one thing I dislike about maemo it's the single menu interface which tends to translate to 3 clicks to do anything, though I suppose some of the changes do lend themselves to extra space for the actual content etc.
I am indeed using 0.13.0. A few points after a few days of use..
- As above, I think i'd like the application a lot with a web aided service, although I wish there was another way. I wonder if maybe a compromise might be a small RPC style service to take a feed, order and/or shorten it, then return it to the application which could process it more quickly, now being able to make some assumptions. Then of course, the fall back to the service being unavailable could be the original method, so it would continue to work. That might not be as lightning fast as having a remote server do all the work, but it might create less of a dependency. The alternative seems to be something updating feeds on server, on a schedule, similar to Google Reader. I'd imagine that would be fastest, but be a huge dependency and be more complicated to code.
- The database stuff (displaying episode lists) has a little lag too although I suspect you've got that as tight as you're going to get it in an interpreted language. That's perfectly bearable and doesn't seem much slower on the larger stored feeds. No slower than Video Center's similar functionality.
- The parsing speed on a morning where only 3 feeds had changed was quite bearable. It's when a lot of people push out content at the same time the time gets harder to take. 5-15 minutes seems to be the range for my now 19 feeds, although this gets done in the hazy first 30 minutes after having woken up so I may be distorting time in my mind
- This morning I let it launch into 5 downloads at once. The interface didn't move again until three of the files had fully downloaded, then I saw the final two progress together. I will try configuring it to do 2 at a time tomorrow as I've only just noticed it's an option. It feels more like the downloads are maxing the processor out rather than the connection. Does it/can it yield at all during downloads?
- I am having trouble adding a feed. It failed to add from the OPML (the only one as far as I can see) and now it won't let me add it from the interface. It seems fine in the desktop version. The only thing I can think of is that the domain has a hyphen - it's http://www.manager-tools.com/feed. No other URLs in my list contain a hyphen.
Things I thought that aren't dealbreakers but I'd probably like to see. Feel free to ignore these :
- A startup page might be preferable to the top feed in the list being fully displayed. From what I can see this would give the user access to the interface a little more quickly. When in verbose it looked like most of the startup time is spent loading that feed. After a few days I realise i'm barely noticing this delay. Video Center by comparison takes ages to start up, although it didn't in older versions.
- Another thing I like about Video Center is the little list of recent downloads. Again, from a speed point of view, if there was a way to list the four files I'd just downloaded in one view and hit play, it would feel faster than having to display the feed to get to the downloaded episode. Do they need to disappear from the Downloads window as soon as they're downloaded?
Hope some of this is helpful. Thanks again for your response!
One possibility would be to have a web service carry out the hard work and make gPodder only "read" the data from the webservice without any heavy lifting done. This would make things really (I mean, really, really!) fast (in terms of checking for updates), but would of course make gPodder dependent on such a web service.
I definitely like the look and feel of the application. Ironically when I first tried to use it in verbose mode I missed off the maemo flag and launched it with the normal interface and thought it fitted quite well. If there's one thing I dislike about maemo it's the single menu interface which tends to translate to 3 clicks to do anything, though I suppose some of the changes do lend themselves to extra space for the actual content etc.
Have you tried the latest Maemo version (0.13.0) of gPodder yet? If so, is it just the parsing speed of feeds thare you don't like? How would you like gPodder if parsing was blazingly fast (with the added dependency on a web service)? Thanks for your feedback!
- As above, I think i'd like the application a lot with a web aided service, although I wish there was another way. I wonder if maybe a compromise might be a small RPC style service to take a feed, order and/or shorten it, then return it to the application which could process it more quickly, now being able to make some assumptions. Then of course, the fall back to the service being unavailable could be the original method, so it would continue to work. That might not be as lightning fast as having a remote server do all the work, but it might create less of a dependency. The alternative seems to be something updating feeds on server, on a schedule, similar to Google Reader. I'd imagine that would be fastest, but be a huge dependency and be more complicated to code.
- The database stuff (displaying episode lists) has a little lag too although I suspect you've got that as tight as you're going to get it in an interpreted language. That's perfectly bearable and doesn't seem much slower on the larger stored feeds. No slower than Video Center's similar functionality.
- The parsing speed on a morning where only 3 feeds had changed was quite bearable. It's when a lot of people push out content at the same time the time gets harder to take. 5-15 minutes seems to be the range for my now 19 feeds, although this gets done in the hazy first 30 minutes after having woken up so I may be distorting time in my mind
- This morning I let it launch into 5 downloads at once. The interface didn't move again until three of the files had fully downloaded, then I saw the final two progress together. I will try configuring it to do 2 at a time tomorrow as I've only just noticed it's an option. It feels more like the downloads are maxing the processor out rather than the connection. Does it/can it yield at all during downloads?
- I am having trouble adding a feed. It failed to add from the OPML (the only one as far as I can see) and now it won't let me add it from the interface. It seems fine in the desktop version. The only thing I can think of is that the domain has a hyphen - it's http://www.manager-tools.com/feed. No other URLs in my list contain a hyphen.
Things I thought that aren't dealbreakers but I'd probably like to see. Feel free to ignore these
:- A startup page might be preferable to the top feed in the list being fully displayed. From what I can see this would give the user access to the interface a little more quickly. When in verbose it looked like most of the startup time is spent loading that feed. After a few days I realise i'm barely noticing this delay. Video Center by comparison takes ages to start up, although it didn't in older versions.
- Another thing I like about Video Center is the little list of recent downloads. Again, from a speed point of view, if there was a way to list the four files I'd just downloaded in one view and hit play, it would feel faster than having to display the feed to get to the downloaded episode. Do they need to disappear from the Downloads window as soon as they're downloaded?
Hope some of this is helpful. Thanks again for your response!
The version I am using is 0.12.3. I don't exactly remember from where I downloaded it...could be from gpodder.org site.
I am still confused about diablo/chinook/debian etc etc though I do know that some of them are names of OS (though I don't know which one is OS2007 and which one is OS2008) but I have OS 2008 with latest update that brings easy updates and browser stability. Thanks a lot for all that feedback. I do hope that you guys will be able to bring new version soon (0.13).