Unhappy with current state of Linux podcasting receivers

[snarkout]

I bow down before your mighty CLI fu.

[snarkout]

Here's an interesting problem I've been having recently - amarok is only downloading the first 5 to 15 minutes of my podcasts - it's strange. I haven't seen any other reports of similar issues, and I can't figure out what would be causing it. Looking at debug info, nothing is crashing, it just hangs for a long ass time, and then ends w/o downloading the entire podcast. It doesn't say TIMING OUT, NO YUO!!!!! - there's no output at all actually, other than a message about the progress bar, and watching the progress bar, it just hangs at the same point every over and over, and then just goes poof. I get 6 minutes of an hour long podcast.

It used to be a once in a while thing, now it happens all the time. It seems like if I delete the entire podcast entry and re-add it, the problem goes away for a while. This could also be complete chance. I have no idea wtf is going on, or if the issue is even related to amarok. I've dicked around with tcp windowing since there's been a lot of talk on that and the 2.6.17 kernel recently, and came up dry - not surprising since I can't say I've had any other internet related issues recently. Maybe I'll take a peek at some of the catchers mentioned in this thread until I can figure out wtf is happening.

[snarkout]

Ah - ok - after poking around some, it appears that the downloads are happening just fine, but amarok is calculating the times of the shows incorrectly. While taking a serious look at what could be the isseu, I noticed that a) even when the progress bar in amarok was stalled I was still downloading a lot of data, and b) the size of the shows was all consistenet with a full sized show. Amarok, however, was reporting them as very short. Opening them from the command line with mplayer showed shows of about an hour apiece. Playing the shows in amarok was interesting - the progress slider would move all the way to the end, and then continue playing. Somehow, though, when these were transferred to my ipod it either only got a few minuted of the 'cast, or it honored the time instead of the length of the total podcast. I've heard of similar issues in the past - I think it had something to do with some types of VBR mp3s. Interesting.

In any event - it seems like the issue is easily solved by going to the top level "podcasts" directory, right clicking, and choosing "Refresh All Podcasts." It's strange how long it took me to ts this...

[CptnObvious999]

Snarkout did you make sure you configured each feed to "Download when available"? Also what version of Amarok are you using? You might also want to try backing up and deleting the ~/.kde/share/apps/amarok folder

[snarkout]

Yes, I do the first thing you mention every time I add a podcast - I have also reset them to default behavior, and even chosen separate directories for each podcast. I have removed podcasts and readded them. I have also blown away my amarokrc and the entire amarok directory a few times. I'm running 1.4.2 currently, but had the same problems with 1.4.1. As long as I can fix the issue with a few mouse clicks, I guess I don't mind, in any event. It is a weird one, though. I'd file a bug report if I could find anything to indicate what the problem is, or that anyone else is seeing this same issue.

[snarkout]

Found the bugreport:

http://bugs.kde.org/show_bug.cgi?id=130185

[snarkout]

Upgraded to 1.4.3 didn't fix the issue - it doesn't look like anyone in the amarok camp is working towards a fix for this. Also, I was wrong about my easy workaround - it only works occasionally. I guess it's back to another catcher and hoping amarok will see the files correctly. Otherwise it's back to gnupod for me. If that even works anymore - I guess if it plays in iTunes, it's good enough for most folks.

[snarkout]

This is really fscking weird. I can drag a "broken mp3" from amarok to my desktop and then back to amarok, and magically it has all the right info. It's very, very strange. If it's a broken tag issue, then WTF would this "fix" the issue?

In any case, I found an amarok script called mp3fixer that has worked perfectly on everything so far. If you've been hit by this issue, check this script out.

I'll also make a blog post about this, I guess.

[btyson]

Bashpodder will not re-download a file that has already been downloaded - *unless* the URL of the feed changes.

I have been using BashPodder, and I agree with this statement. But I am curious, how does it know which have already been downloaded?

Thank you.

[Gomer_X]

Bashpodder will not re-download a file that has already been downloaded - *unless* the URL of the feed changes.

I have been using BashPodder, and I agree with this statement. But I am curious, how does it know which have already been downloaded?

Thank you.

During a bashpodder run, a file called 'temp.log' is created with a list of all the URLs of the files it's downloading that run. Once the bashpodder run completes, it appends the list in temp.log to podcast.log. So podcast.log is a list of all the podcasts bashpodder has ever downloaded.

Next run, bashpodder compares a URL agains podcast.log, and if it's in there, it doesn't download it again. If you get a bad download, delete that line from podcast.log and bashpodder will download it again.

[Linc]

During a bashpodder run, a file called 'temp.log' is created with a list of all the URLs of the files it's downloading that run. Once the bashpodder run completes, it appends the list in temp.log to podcast.log. So podcast.log is a list of all the podcasts bashpodder has ever downloaded.

Next run, bashpodder compares a URL agains podcast.log, and if it's in there, it doesn't download it again. If you get a bad download, delete that line from podcast.log and bashpodder will download it again.

Yup!

[btyson]

During a bashpodder run, a file called 'temp.log' is created with a list of all the URLs of the files it's downloading that run. Once the bashpodder run completes, it appends the list in temp.log to podcast.log. So podcast.log is a list of all the podcasts bashpodder has ever downloaded.

Next run, bashpodder compares a URL agains podcast.log, and if it's in there, it doesn't download it again. If you get a bad download, delete that line from podcast.log and bashpodder will download it again.

Thanks for this information. So the way most feeds seem to be set up (with every episode in the feed) it is important not to delete the older listings from the log, am I right?

BTW thanks Linc for creating BashPodder.

[Linc]

Thanks for this information. So the way most feeds seem to be set up (with every episode in the feed) it is important not to delete the older listings from the log, am I right?

BTW thanks Linc for creating BashPodder.

That depends on the rss feed. Some people keep every show in their feeds (and their feeds are huge) and some only keep 5 or 10. If there are only 5 or 10, deleting the old ones out of the log won't matter. If they have them all and you delete one, you'll re-download it.