Active Topics
-
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (3)
to SailfishOS by edp17 - 6 hrs, 36 mins ago -
The N900 is now 15 years old! (6)
to Nokia N900 by Macros - 1 day, 10 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 1 day, 23 hrs ago -
n770 youtube video (0)
to General by nmdv - 5 days, 22 hrs ago - more...
 |
|
2009-06-18
, 09:52
|
|
Posts: 1,391 |
Thanked: 4,272 times |
Joined on Sep 2007
@ Vienna, Austria
|
#292
|
Originally Posted by onion_cfe
When do the download stop? Always at the beginning, always at the end or always at some random spot in between? Can you also please tell me the feed URL for the podcast, so I can try to reproduce the bug here? The timeout means "no activity for 60 seconds", the speed is irrelevant (i.e. a download running at a constant 6kb/s with data coming in all the time will still not timeout).
This 60 second download timeout is killing my use of the program. I can watch it fail after sometimes 0%, 1%, another at 22%, then can watch microb on the tablet or Firefox on my laptop download it quite successfully, albeit slowly.
Is the timeout actually the issue though or is it the fact that the download is stopping, later causing the timeout? I'm dealing with an awful DSL ISP (I was warned about BT and didn't listen - huge idiot with 8 months left on the contract) and often these downloads will legitimately be moving at 30-40Kibps, but they will be moving. The downloads don't stop moving anywhere but gPodder.
This doesn't seem to be a widespread problem. D'you think I should try a clean flash? I did play around with that maemo-pc-connectvitiy package a few days ago and that didn't go too well so I suppose it's possible it's left something behind.
Can I obtain a .deb of the previous version somewhere if I can't get past this?
Here's the URL:http://repository.maemo.org/extras/p...ree/g/gpodder/
Thanks for yours and others continued work on this. Also liked the look of the Maemo 5 build, although I plan to milk my N800 for some time yet so please don't move on too quickly
|
|
2009-06-18
, 16:29
|
|
Posts: 39 |
Thanked: 0 times |
Joined on Aug 2007
|
#293
|
It tends to be closer to the start. More than not it won't pass 0%. Very occasionally it will stop at a random point. It's just happened this minute with this feed: http://www.btpodshow.com/feeds/noagenda.xml, episode NA-105-2009-06-18. In this case it didn't move off 0%. I kicked it off in Firefox seconds later with no problems.
I'll persevere with the current version rather than downgrade as it's not happening all the time. Yesterday it didn't happen once, but the day before when I posted this it happened with almost all downloads. They do also eventually seem to work after closing down and reopening a few times.
Here's the verbose for the failure I just had:
I can't say i'm entirely convinced that this isn't in some way related to my setup, but as I said it's only been happening since the latest version so it's worth looking into.
Cheers,
Tom.
I'll persevere with the current version rather than downgrade as it's not happening all the time. Yesterday it didn't happen once, but the day before when I posted this it happened with almost all downloads. They do also eventually seem to work after closing down and reopening a few times.
Here's the verbose for the failure I just had:
Code:
[ 174.406] (DownloadQueueManager) I am going to spawn a new worker thread. [ 174.409] (DownloadQueueWorker) Running new thread: Thread-4 [ 174.411] (DownloadQueueWorker) Thread-4 is processing: NA-105-2009-06-18 [ 234.788] (DownloadTask) Error "timed out" while downloading "NA-105-2009-06-18": None [ 234.791] (DownloadQueueWorker) No more tasks for Thread-4 to carry out. [ 235.760] (gPodder) All downloads have finished.
Cheers,
Tom.
|
|
2009-06-18
, 17:17
|
|
Posts: 1,391 |
Thanked: 4,272 times |
Joined on Sep 2007
@ Vienna, Austria
|
#294
|
Originally Posted by onion_cfe
Ok, I've backported a patch from the current development tree to the 0.16.1 Maemo package that fixes hanging downloads at 100%; maybe it fixes your problem as well. The resulting package (0.16.1-2) will be available in Diablo Extras-Devel and Chinook Extras-Devel soon (currently in the autobuilder).
It tends to be closer to the start. More than not it won't pass 0%. Very occasionally it will stop at a random point. It's just happened this minute with this feed: http://www.btpodshow.com/feeds/noagenda.xml, episode NA-105-2009-06-18. In this case it didn't move off 0%. I kicked it off in Firefox seconds later with no problems.
|
|
2009-06-18
, 17:58
|
|
Posts: 1,391 |
Thanked: 4,272 times |
Joined on Sep 2007
@ Vienna, Austria
|
#295
|
Originally Posted by onion_cfe
I've just created a short tutorial on how to capture the HTTP headers of gPodder downloads on the device that will be helpful for bug reporting:
It tends to be closer to the start. More than not it won't pass 0%. Very occasionally it will stop at a random point. It's just happened this minute with this feed: http://www.btpodshow.com/feeds/noagenda.xml, episode NA-105-2009-06-18. In this case it didn't move off 0%. I kicked it off in Firefox seconds later with no problems.
Reporting download problems
|
|
2009-06-19
, 17:20
|
|
Posts: 39 |
Thanked: 0 times |
Joined on Aug 2007
|
#296
|
Okay, got the update. No problems yet today, and got the capture tool ready if and when it happens again, so i'll let you know. Thanks for looking at this.
Cheers,
Tom.
Cheers,
Tom.
|
|
2009-06-20
, 07:28
|
|
Posts: 39 |
Thanked: 0 times |
Joined on Aug 2007
|
#297
|
I've had another timeout this morning and have followed your instructions. I will post a bug if you wish but first I'd like to check something.
tcpdump when I killed it reported 11230 packets captured, 17780 received by filter and 6550 packets dropped be kernel. That last one sounds suspicious.
I also noted a few times that when the timeouts were allowing me to make no progress, the only way to recover was to reconnect the wireless. Does the above and this not perhaps point to this being my problem?
This timeout was the second timeout of the session at 56% after one at around 30% which I wasn't capturing. The throughput was much higher during this one, reported at 300KiB/s plus (my service is best in the early morning).
Tapping Download again led to no movement. Cycling offline and online again causing the wireless to reconnect and then tapping Download led to the file resuming at good speed.
This now gets more confusing. it didn't time out again, but it decided it was finished at 97%. I checked the show and it was definitely missing the end.
On deleting the show and trying again to download it it timed out many more times, until one point when I cycled the wireless it went through to 100% in one go.
Here are the headers from the earlier timeout:
GET /shows/RBR-06-19-09.mp3 HTTP/1.0
Host: redbarradio.com
User-Agent: gPodder/0.16.1 (+http://gpodder.org/)
Range: bytes=27574272-
HTTP/1.1 206 Partial Content
Date: Sat, 20 Jun 2009 06:19:36 GMT
Server: Apache/1.3.41 (Unix) mod_log_bytes/1.2 mod_bwlimited/1.4 mod_ssl/2.8.31 OpenSSL/0.9.8b
Last-Modified: Sat, 20 Jun 2009 06:19:36 GMT
ETag: W/"6d04234-4c437ef-4a3c9f0a"
Accept-Ranges: bytes
Content-Length: 52393967
Content-Range: bytes 27574272-79968238/79968239
Connection: close
Content-Type: audio/mpeg
Let me know what you think.
Cheers,
Tom.
tcpdump when I killed it reported 11230 packets captured, 17780 received by filter and 6550 packets dropped be kernel. That last one sounds suspicious.
I also noted a few times that when the timeouts were allowing me to make no progress, the only way to recover was to reconnect the wireless. Does the above and this not perhaps point to this being my problem?
This timeout was the second timeout of the session at 56% after one at around 30% which I wasn't capturing. The throughput was much higher during this one, reported at 300KiB/s plus (my service is best in the early morning).
Tapping Download again led to no movement. Cycling offline and online again causing the wireless to reconnect and then tapping Download led to the file resuming at good speed.
This now gets more confusing. it didn't time out again, but it decided it was finished at 97%. I checked the show and it was definitely missing the end.
On deleting the show and trying again to download it it timed out many more times, until one point when I cycled the wireless it went through to 100% in one go.
Here are the headers from the earlier timeout:
GET /shows/RBR-06-19-09.mp3 HTTP/1.0
Host: redbarradio.com
User-Agent: gPodder/0.16.1 (+http://gpodder.org/)
Range: bytes=27574272-
HTTP/1.1 206 Partial Content
Date: Sat, 20 Jun 2009 06:19:36 GMT
Server: Apache/1.3.41 (Unix) mod_log_bytes/1.2 mod_bwlimited/1.4 mod_ssl/2.8.31 OpenSSL/0.9.8b
Last-Modified: Sat, 20 Jun 2009 06:19:36 GMT
ETag: W/"6d04234-4c437ef-4a3c9f0a"
Accept-Ranges: bytes
Content-Length: 52393967
Content-Range: bytes 27574272-79968238/79968239
Connection: close
Content-Type: audio/mpeg
Let me know what you think.
Cheers,
Tom.
|
|
2009-06-21
, 14:41
|
|
Posts: 1,391 |
Thanked: 4,272 times |
Joined on Sep 2007
@ Vienna, Austria
|
#298
|
Originally Posted by onion_cfe
Sounds like, yes. Maybe try another Wifi Access Point and see if this problem persists?
I also noted a few times that when the timeouts were allowing me to make no progress, the only way to recover was to reconnect the wireless. Does the above and this not perhaps point to this being my problem?
This timeout was the second timeout of the session at 56% after one at around 30% which I wasn't capturing. The throughput was much higher during this one, reported at 300KiB/s plus (my service is best in the early morning).
Tapping Download again led to no movement. Cycling offline and online again causing the wireless to reconnect and then tapping Download led to the file resuming at good speed.
This now gets more confusing. it didn't time out again, but it decided it was finished at 97%. I checked the show and it was definitely missing the end.
|
|
2009-06-21
, 21:26
|
|
Posts: 4,556 |
Thanked: 1,624 times |
Joined on Dec 2007
|
#299
|
Hmm is there any alternative way of updating without updating one feed at a time to prevent crashes or lock ups on the tablet?
__________________
Originally Posted by ysss
They're maemo and MeeGo...
"Meamo!" sounds like what Zorro would say to catherine zeta jones... after she slaps him for looking at her dirtily...
|
|
2009-06-21
, 21:52
|
|
Posts: 1,391 |
Thanked: 4,272 times |
Joined on Sep 2007
@ Vienna, Austria
|
#300
|
The next version will have the feed updates happen in serial, not in parallel. This should prevent crashes. Although it might cause the feed update to be a bit slower.
Most of the recent changes are great. Unfortunately...
This 60 second download timeout is killing my use of the program. I can watch it fail after sometimes 0%, 1%, another at 22%, then can watch microb on the tablet or Firefox on my laptop download it quite successfully, albeit slowly.
Is the timeout actually the issue though or is it the fact that the download is stopping, later causing the timeout? I'm dealing with an awful DSL ISP (I was warned about BT and didn't listen - huge idiot with 8 months left on the contract) and often these downloads will legitimately be moving at 30-40Kibps, but they will be moving. The downloads don't stop moving anywhere but gPodder.
This seemed to change for me between 0.16.1-1 (current) and the one just before it. I thought I saw it a bit in the previous version but it was only on one particular show and I was using poor WiFi connectivity out and about. Now it's happening a lot more. I definitely never had the issue with the old download manager, but I also don't think I had it when you first introduced the new one - i've lost track.
This doesn't seem to be a widespread problem. D'you think I should try a clean flash? I did play around with that maemo-pc-connectvitiy package a few days ago and that didn't go too well so I suppose it's possible it's left something behind.
Can I obtain a .deb of the previous version somewhere if I can't get past this?
Thanks for yours and others continued work on this. Also liked the look of the Maemo 5 build, although I plan to milk my N800 for some time yet so please don't move on too quickly