Played same podcast on Squeezeplay running on an Ubuntu system.
Interesting - I played the podcast using Squeezeplay but also kept open
Web GUI.
Squeezeplay starts at 0:20 (perhaps this is est. time relating to data
in output buffer) but WebGUI seems to indicate that elapsed time was
about 20
bpa wrote:
> I just played the Rachel Meadows podcast - from start to finish looking
> at the timebar on the Default not Material UI. It starts with the
> -46:23 time (i.e. time left to play) and then gets updated to -45:14.
> It played right through the end stopping without chopping off end
I just played the Rachel Meadows podcast - from start to finish looking
at the timebar on the Default not Material UI. It starts with the
-46:23 time (i.e. time left to play) and then gets updated to -45:14.
It played right through the end stopping without chopping off end of
podcast (and ti
bpa wrote:
> Have you started an independent timer as well ? you can't rely on the
> LMS on screen timer as it may do odd things if playing duration overuns
> calculated duration.
Next time... The duration in the XML file is 47:53. LMS calculated it to
46:47. It stopped at 46:26. When I
dolodobendan wrote:
> I just started the latest podcast (XML: 47:53, corrected to 46:47).
> Let's see what happens.
Have you started an independent timer as well ? you can't rely on the
LMS on screen timer as it may do odd things if playing duration overuns
calculated duration.
I just started the latest podcast (XML: 47:53, corrected to 46:47).
Let's see what happens.
QLMS 7.9.2@2.04 x64 (digimaster) with perl 5.28 dedicated to me. :D /
QNAP 469L QTS 4.3.4
dolodobendan's Profile:
mrw wrote:
> There have been a few examples of a few 'sloppy feeds' over the last
> twelve months or so, hence some of the relatively recent changes.
>
> And there is also the possibility of an 'Atom' feed.
I've come across lots of bad feeds and bad in a variety of ways. NPR
had characters
bpa wrote:
> All pointing to a sloppy standard and a sloppy feed.
There have been a few examples of a few 'sloppy feeds' over the last
twelve months or so, hence some of the relatively recent changes.
And there is also the possibility of an 'Atom' feed.
After understanding the various numbers and their sources - I added the
Rachel Meadows the the Podcast Tab which appears via My Apps (not the
Radio/Podcast).
The test podcast "Omar cites corruption" shows up on the podcast feed
and drilling down shows the duration as 2783 (i.e. 46:23)
When
bpa wrote:
>
> A reference to the RSS 2.0 spec (all of one page) - strange that it is
> kept at Harvard - not a well known standards body.
> https://cyber.harvard.edu/rss/rss.html
>
Dave Winer (well known in 80s) is the author of the original RSS spec
and is/was a fellow there.
Paul
FYI
Apple rules on what they accept in a podcast feed and the feed must be
validated by Apple to be accepted on iTunes
https://help.apple.com/itc/podcasts_connect/#/itcb54353390
Interesting that "enclosure" is a required tag with length but while
Apple validate the filed is present they do
dolodobendan wrote:
> My head is still spinning, but I'll give it a whirl tomorrow.
>
> But I still wonder: LMS changes/calculates the duration some seconds
> after the podcast starts. So it uses the calculated time from that point
> on and not the XML time. Why stop early?
Trawling through
bpa wrote:
> I think the estimated duration is the correct method - when I play the
> 45:13 URL in Chrome - it too shows 45:13.
>
> The XML value is plain wrong.
>
> The question now is understand where the other number come from.
> Multiple the various duration times by 12,000 to get a byte
dolodobendan wrote:
> I see the problem. But shouldn't this problem exist for iTunes or
> whatever other people use as well? If not, why not?
I think the estimated duration is the correct method - when I play the
45:13 URL in Chrome - it too shows 45:13.
The XML value is plain wrong.
The
My respect.
Now the playing time is 45:17 (LMS) and 45:13 (VLC). I will play the
whole podcast tomorrow again. It should play to the end now, right? LMS
shows 45:17 while it is 45:13. No reason to stop before it runs out of
bytes?
QLMS 7.9.2@2.04 x64 (digimaster) with perl 5.28 dedicated to
FRagment of code from Slim/Utils/Scanner/Remote.pm
Code:
# Parse tags and bitrate
my $bitrate = -1;
my $vbr;
my $cl = $http->response->content_length;
my $type= $track->content_type;
my
Looking through code and file in more detail.
AFAICT There is no ID3 tag TLEN in use. It looks like the duration has
been calculated by the length of the file (minus ID3 header & art work
bytes) divided by bitrate (96000kbps = 12000 bytes/sec)
File size is 32,611,627
art work is 43,782
ID3
bpa wrote:
> Example of the issues from the NBC news feed you ref
>
> The XML for one item in the list. When parsing the XML it is assumed to
> be playlist and the *itunes:duration* and *enclosure* are the main items
> used items. Note the use of itunes tags and also *length* is zero !!
> >
Example of the issues from the NBC news feed you ref
The XML for one item in the list. When parsing the XML it is assumed to
be playlist and the *itunes:duration* and *enclosure* are the main items
used items. Note the use of itunes tags and also *length* is zero !!
Code:
bpa wrote:
> First there is no hard defined international (e.g. ISO, IEEE, IETF)
> standard for management of podcasts. A lot of what is used is de-facto
> and has evolved as "normal" or "usual". So many of the norms were
> initially defined & used by Apple & iTunes but "extended" by others to
First there is no hard defined international (e.g. ISO, IEEE, IETF)
standard for management of podcasts. A lot of what is used is de-facto
and has evolved as "normal" or "usual". So many of the norms were
initially defined & used by Apple & iTunes but "extended" by others to
accommodate non
bpa wrote:
> In the case of the BBC - there have been programmes which comment on the
> news - after broadcast legal action is taken and so some items were
> removed.
> In other cases, a discussion talked about a topic (e.g. suicide,
> terorist attack) and shortly afterwards a real similar
bpa wrote:
> All duration at teh start of playing an MP3 are estimates based on size
> and data rate of the file. I'm not sure but I think the data rate is
> not accurate (i.e. 64kbps will not be 64kbps for 100% of the file but
> should be the close to that figure for the whole file) it is
dolodobendan wrote:
> I 'downloaded this feed'
> (http://media.adknit.com/a/f/11/anderson-cooper-360/el0b8v.1-1.mp3) and
> here it's also 2455 seconds (40:55m).
>
> Episode overview in LMS: Duration reported as 2353s (39:13m)
> Episode duration reported while playing: 2509s (41:49m)
>
> Maybe
Same here
gary's Profile: http://forums.slimdevices.com/member.php?userid=269
View this thread: http://forums.slimdevices.com/showthread.php?t=109017
___
Squeezecenter mailing
I have noticed this as well with certain podcast feeds/streams.
hephepphepp's Profile: http://forums.slimdevices.com/member.php?userid=66879
View this thread: http://forums.slimdevices.com/showthread.php?t=109017
Now I listened to this episode two more times (not as fun as one might
think) and it stopped both times around 38:30m. The first time was at
38:30m, the second time at 38:25m.
QLMS 7.9.2@1.08 (digimaster) / QNAP 469L QTS 4.3.4
bpa wrote:
> Since podcats is 40 mins long it take time to test but there is an
> interesting discrepancy: feed says duration is 2353 secs but when is it
> played by LMS (and also mplayer) - they both give a duration of 2455 -
> about 1min40 secs longer.
I 'downloaded this feed'
bpa wrote:
> It makes life easier for other to test when there is a specific and you
> do imply that it only happens to some podcasts.
Maybe I use the term "podcast" incorrectly. I always thought of podcasts
as a collection of episodes. (On the same server, so the specific
episode is not
bpa wrote:
> Since podcats is 40 mins long it take time to test but there is an
> interesting discrepancy: feed says duration is 2353 secs but when is it
> played by LMS (and also mplayer) - they both give a duration of 2455 -
> about 1min40 secs longer.
I'll check later if other episodes and
Since podcats is 40 mins long it take time to test but there is an
interesting discrepancy: feed says duration is 2353 secs but when is it
played by LMS (and also mplayer) - they both give a duration of 2455 -
about 1min40 secs longer.
dolodobendan wrote:
> If the specific episode really matters, ok...
It makes life easier for other to test when there is a specific and you
do imply that it only happens to some podcasts.
bpa's Profile:
bpa wrote:
> The links you gave included many podcasts - give the specific example.
This "feels" like a player buffer related issue- what player are you
using ?
What version of LMS.
How do you start the podcast ?
If the specific episode really matters, ok...
It was "The Story Denied, The
The links you gave included many podcasts - give the specific example.
This "feels" like a player buffer related issue- what player are you
using ?
What version of LMS.
How do you start the podcast ?
bpa's Profile:
Again, the podcast came to an early end. It stopped around the time of
the last entry (13:34h).
That's the server log for today:
Code:
[18-05-06 13:09:58.7458] Slim::Plugin::Podcast::Plugin::songChangeCallback
(122) Setting up timer to track podcast progress...
I listened to two CNN podcasts today, 'this one'
(http://feeds.adknit.com/app-search/cnn/state-of-america/all/720/200/)
and 'this one'
(http://feeds.adknit.com/app-search/cnn/anderson-cooper-360/all/1080/200/).
Both stopped playing roughly one minute before they were supposed to
end. When I
36 matches
Mail list logo
