get_iplayer forums

--tracklist gives erroneous offsets - Printable Version

+- get_iplayer forums (https://forums.squarepenguin.co.uk)
+-- Forum: General Forums (https://forums.squarepenguin.co.uk/forum-16.html)
+--- Forum: General Topics (https://forums.squarepenguin.co.uk/forum-15.html)
+---- Thread: --tracklist gives erroneous offsets (https://forums.squarepenguin.co.uk/thread-2053.html)



--tracklist gives erroneous offsets - benshepherd - 03-07-2019

Downloading Stormzy's Glastonbury set from BBC 1Xtra, and adding the tracklist using --tracklist. Some of the times are incorrect in the tracklist file. Here's a snippet:

Code:
Glastonbury: 2019
Stormzy Live!
2019-06-28
https://www.bbc.co.uk/programmes/m0006gcr
--------
00:11:06
Stormzy
Intro (Glastonbury 2019)
Duration: 00:04:01
--------
00:12:24
Stormzy
Know Me From (Glastonbury 2019)
Duration: 00:04:01
--------
00:46:11
Stormzy
Cold (Glastonbury 2019)
Duration: 00:04:01
--------
00:18:40
Stormzy
First Things First (Glastonbury 2019)
Duration: 00:04:01

It's clear that the start time for 'Cold' can't be at 46:11, since the next track is at 18:40. The json file has the track starting at 15:34 (version_offset: 934 seconds).

There are two track time errors like this. The rest seem to match up with the JSON file. Any thoughts?


RE: --tracklist gives erroneous offsets - dinky - 03-07-2019

GIGO - look carefully at the entries for "Cold" and "Crown". Track data is often bad.


RE: --tracklist gives erroneous offsets - benshepherd - 03-07-2019

Yeah, I understand that get_iplayer has to work with what it gets. But it gets the track data from the JSON file, right? And the version_offset numbers in that file look OK for those two tracks.


RE: --tracklist gives erroneous offsets - dinky - 03-07-2019

But how does it identify which offset to use? Keep looking - you'll find the problem.


RE: --tracklist gives erroneous offsets - benshepherd - 03-07-2019

I'm not getting it. "Cold" and "Crown" look to have the same data as all the other tracks. I'm sorry, I'm obviously stupider than you're giving me credit for!


RE: --tracklist gives erroneous offsets - dinky - 04-07-2019

(03-07-2019, 01:51 PM)benshepherd Wrote: I'm not getting it. "Cold" and "Crown" look to have the same data as all the other tracks
I don't know what JSON you're looking at - that is completely false, and it wouldn't even make sense. Still, you've accidentally stumbled on the heart of the matter. It's what those entries have in common that causes the problem.


RE: --tracklist gives erroneous offsets - benshepherd - 04-07-2019

Yes, I'd worded that badly - sorry. I meant that neither of those entries seemed to have anything missing.

This is the JSON I'm looking at.

I think I see what you mean now - the record_id is the same for both tracks, and get_iplayer is using it as a key. So couldn't you just ignore it, and use the JSON data as an array instead?


RE: --tracklist gives erroneous offsets - dinky - 04-07-2019

With the BBC threatening to junk the JSON data, it didn't seem a good idea at the time. And it hardly matters, anyway. You can't produce accurate track timings from that data even when it isn't broken. But a track list isn't much use without some approximation of where the tracks are in the programme.


RE: --tracklist gives erroneous offsets - benshepherd - 04-07-2019

Yes - I realised the timings were crap when I listened back to it last night. But in principle it would work quite nicely - it seems to work well with other radio programmes that I've tried. For instance, Steve Lamacq's show from Tuesday gives the track timings, which I turn into a cue sheet with my Python script. I can play the cue sheet on Windows with 1by1, and all the timings seem to match up nicely.

I started downloading some of the Glastonbury sets, and Stormzy's was the first one I got. I noticed the tracklist thing, which I hadn't known about before, and I thought "that'll be handy for knowing which track is playing". Unfortunately of the sets I was interested in, it was only Stormzy and The Killers that had track lists.

Thanks for your help.