Open holgerkrupp opened 8 years ago
Ok, the big issues are solved. Only the overview doesn't show the right value. To do this, the duration should be checked after parsing the feed (to check with files that have been downloaded). Needs only to be done where the duration is 00:00:00 (I just hope that the other dates are right).
With the current implementation, the duration is checked when the player is loaded and has initialised the media file. with this, all the 'Player elements' are working.
There is also an issue when there is no duration in the feed.
Do you have a feed with an example?
For example: http://sternengeschichten.podspot.de/rss
Items do not contain a <itunes:duration>
tag, so episode.duration is empty.
(Your intention is to make this customizeable, right?)
Yes it should be customisable. I'm currently finishing it for my podcast (and for a podcast of a friend). Both are Podcasts with the iTunes tags inside. Afterwards I'm going to implement some specialises.
I've put a new function inside to read the duration from the episode information. if the duration is nil or empty, it returns 0. That should solve the crash. The duration information for the episodes are read from the media files as soon as the player is started. So you have the information within the player, but not within the list.
if inside the feed one element has a duration set to 00:00:00 as shown in the code below, the duration of the episode is not well managed. The effect is that the time the episode is played, is always greater than the time the episode is in reality, leading to the fact that the episode is marked as played.
<enclosure url="hit […] m4a" length="27897072" type="audio/mp4" /><itunes:duration>00:00:00</itunes:duration><itu…
As we don't have always influence in the feed, the solution is to catch this case and just don't show a process. As so as the episode has been loaded, the duration can be updated within the App (until the feed is parsed again).