This is not a big problem since I can work around it, but it's something of an inconsistency and might indicate a bug in the metadata handling code (or a bug in my understanding of how  to use get_iplayer?!)? Since installing get_iplayer 3.00-windows.0 a couple of downloads have appeared without any metadata tags in them. It's not something I've ever noticed before.

I'm on Windows10 and I use the following line to download:
get_iplayer --get --pid p02gyz6b --ffmpeg %FFMPEG% --output %ODIR% --tvmode best --fps50 --ffmpeg-force --subtitles --thumb


If I add "--metadata-only --metadata-format generic" to the command line I get a perfectly reasonable looking xml file. And running with the --debug flag looks like it picks up the metadata and reports no obvious error I could see.

The PID example above is Adam Curtis Bitter Creek. I've had the same problem with another Adam Curtis film, HyperNormalisation p04b183c, and also the film Rescue Dawn (which is no longer available). Other downloads (using the same command line, which is scripted) have been OK.

Thanks.

Why do think the metadata is missing? In other words, how did you check it?

I have dbPowerAmp which includes an "Edit ID-Tag" tool. Usually this shows all the (presumably ID3?) tags that you might expect - Artist, Title, Album, Long Description, etc. For these unusual files it  shows the text "Contains no ID Tags" and then empty fields (for artist, title, ....) below it.

In addition, the "Audio Properties" tab on the Windows file explorer properties only shows the filename and type - on previous files it shows other tags/data.

In that case, follow our instructions to provide a full report so we can see what is happening on your system. There is no other way for us to see whether the tagging is broken or not executing. Use --stop=300 so you don't have to download the whole programme.

Following your instructions, I used the --stop=300 flag, and the tags appeared as normal! Typical I thought, it's fixed itself! I re-downloaded the full file. No tags. After a number of attempts with different values of stop, I am now convinced the problem is to do with filesize. Ordering my cache of unwatched downloads by size, sure enough any that were bigger than about 4GB had no tags ; any smaller than that seemed to have the expected tags. Some of those files were from earlier versions of get_iplayer (I had just never noticed the tag problem before), so I don't think the problem is related to the changes in v3.

I haven't established the precise filesize, but it occurs between 4080742 kbytes and 4256557 kbytes (files of those sizes have and do not have tags, respectively), and suspiciously 4x1024x1024 is 4194304 - so I suspect the problem is that the tagging code (AtomicParsley?) is unable to handle files bigger than 4GB.

I can still attach the verbose logs if you like, but looking at the final section where it carries out the tagging, there is no difference that I can see between the logs for a working and a non-working file. I used Winmerge on them and the only difference was the "--year" timestamp within the AtomicParlsey arguments. The last two lines of both files is:

INFO: Command exit code 0 (raw code = 0)
INFO: Tagged file: L:\iPlayerDownloads\Adam_Curtis_-_Bitter_Lake_p02gyz6b_original.mp4

Post the logs

I'll restate this as a standalone problem report, which I hope is more convenient for you.

Certain get_iplayer downloads do not end up with metadata tags attached to them. I have checked this with the Edit ID-Tag tool within dbPowerAmp, and also from the Windows file properties "Audio Properties" tab. The Edit ID-Tag tool reports "Contains no ID Tags".

My experimentation suggests that the problem is caused by filesize - I have 8 or 9 downloaded files  which are over 4GB, and none of them have tags attached (most of these are from before the release of v3, so my initial suggestion that it was a v3 problem is probably wrong).
I have not yet found an example of a file <4GB  with missing tags.

I've put logs on pastebin.

Command line:

get_iplayer --get --pid p02gyz6b --ffmpeg F:\0\Multimedia\ffmpeg\ffmpeg-20170411-f1d80bc-win64-static\bin\ffmpeg.exe --output L:\iPlayerDownloads --tvmode best --fps50 --ffmpeg-force --subtitles --thumb --verbose --force > L:\iPlayerDownloads\log-fullb.txt 2>&1

produces a download with no tags. Log file here:
https://pastebin.com/2pVQLiwW


For comparison, command line:

get_iplayer --get --pid p02gyz6b --ffmpeg F:\0\Multimedia\ffmpeg\ffmpeg-20170411-f1d80bc-win64-static\bin\ffmpeg.exe --output L:\iPlayerDownloads --tvmode best --fps50 --ffmpeg-force --subtitles --thumb --verbose --force --stop=300 > L:\iPlayerDownloads\log-300b.txt 2>&1

produces a download that *does* have tags as expected. Log file here:
https://pastebin.com/BGuz9P8V

For completeness as far as the instructions go:

 - the OS is Windows 10 Home version 1703 OS Build 15063.138

 - the output L: drive is an internal SSD formatted with NTFS.

 - get_iplayer -V returns:
get_iplayer 3.00-windows.0, Copyright (C) 2008-2010 Phil Lewis
  This program comes with ABSOLUTELY NO WARRANTY; for details use --warranty.
  This is free software, and you are welcome to redistribute it under certain
  conditions; use --conditions for details.

  NOTE: A UK TV licence is required to legally access BBC iPlayer TV content

Is this not a problem with AtomicParsley? Did you google some keywords on the issue?

Seems like the 4GB limit is a known issue.

I guess it's relevant to get_iplayer as get_iplayer uses AtomicParsley but it doesn't seem like something fixable by get_iplayer.

If file size is the problem, I can't duplicate it. I had no trouble tagging your programme on Windows 10. Archive programmes like this are not supported by get_iplayer, but I thought there might be a quick win if I could see your log. I see you're not using the provided ffmpeg, which is also unsupported. You might try the provided ffmpeg, though I can't think why it would make any difference. I can't tell from the log, but the behaviour you describe would make sense if you're using an obsolete version of AtomicParsley (<0.94). I can't see how it would be invoked, but if you have an old copy of AP in PATH, it could cause trouble. [EDIT: not using an external drive] I've seen AP choke on big files and not return a error code. Look to see if its temp files are left behind in your output directory. The temp file gets the tags and then replaces the original (get_iplayer invokes AP with the --overWrite option). You could also try writing to your internal disk to see if makes any difference.

Since I can't duplicate the problem, I'm afraid I'll have to leave this for someone else to pick up. If there is a problem with AP, there is nothing get_iplayer could do about it anyway. One suggestion for further testing: Download a copy of the programme without tags by using --no-tag. You can then apply AP to it directly for multiple tests. So long as you don't use --overWrite with AP, it creates a temp file with the tags and leaves the original untouched.

I agree the issue is probably AtomicParsley, although I will experiment some more to be sure. To be honest, until I noticed this problem and started looking at the logs, I had never heard of AtomicParsley, so I wasn't aware it was a separate thing from get_iplayer! Whatever version of it I'm using is the one supplied with get_iplayer - which reports version"0.9.6 (utf16)".

If you're successfully tagging files >4GB, which version of AtomicParsley are you using (and where do I get it??)? My googling is not identifying a newer version.

You have the same version I have. That's the version provided with the installer. There is no newer version.

I also missed that L: was an internal drive. Ignore earlier comment re: slow drives

OK, I'm more confused now. AtomicParsley appears to show that the metadata *is* present in the file - but it's not getting exposed as ID tags as it usually does.

However, I think we've fairly conclusively established that it's not a get_iplayer problem, so I'll take it away and investigate some more!

Thanks for taking a look at it for me.

Well, at least one mystery is solved. Maybe it is a file size issue, just not the one you thought. Get MediaInfo and/or mp3tags and check with those. When I tested your programme, the whatever-is-used in Windows Explorer could see the tags in Properties dialog, but I don't have dbPowerAmp. Different applications might have slightly different notions of how to treat MP4 files. WMP and iTunes are the usual suspects, but it has changed over time.