Re: Possible solution to the Windows AtomicParsley crashes?
On Sat Oct 8 21:21:25 BST 2011, I wrote:
A short-term workaround until I get a patch together is to comment out
lines 4286-4288 in get_iplayer{.pl}, which should look like:
# while ( my ($key, $val) = each %{$meta} ) {
# $meta-{$key} = decode(utf8, $val);
# }
The Wide character warning will still appear, but tagging should work.
Thank you very much :-) ; that works OK with the latest AP on my (test)
file, pid=p00k9js2...
This morning, I have come across another World Service file generating the
Wide character warning;
it has pid=p00kdr09. With the workaround suggested, AP (latest binary) tags
the m4a file, but only
PARTIALLY: The Comment and ©lyr fields (in MediaInfo) contain only the
first word of the
description, i.e. Were (???).
The long description of the file (desc in get_iplayer terminology) can be
read here:
http://www.bbc.co.uk/programmes/p00kdr09
I can spot the offending curly quote in the last paragraph, it's in the
very last Australia's.
However, I am at a complete loss as to why the description isn't properly
written, just its first word :-( .
(I fixed this by opening the m4a with Winamp, copied the description from
the link above and filled the
Comment bit of the tag using Winamp's innate MP4 tagger).
___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Possible solution to the Windows AtomicParsley crashes?
On 8 October 2011 16:33, dinkypumpkin dinkypump...@gmail.com wrote:
On 08/10/2011 16:12, Shevek wrote:
I'm also getting this error now (having never seen it before):
INFO: Recorded
D:\Users\Cyrus\Downloads\iPlayer\Stuart_Maconies_Freakier_Zone_-_08_10_2011_b015gv6n_default.m4a
Wide character in print at get_iplayer.pl line 3530.
INFO: Downloaded Thumbnail to
'D:\Users\Cyrus\Downloads\iPlayer\Stuart_Maconies_Freakier_Zone_-_08_10_2011_b015gv6n_default.jpg'
Cannot decode string with wide characters at Encode.pm line 174.
Same problem as Vangelis - the dreaded curly quote. I wonder if the Beeb
has changed how they author the metadata. These characters can derive from
smart quotes in source text, thanks to MS Word or other word processing
app.
A short-term workaround until I get a patch together is to comment out lines
4286-4288 in get_iplayer{.pl}, which should look like:
# while ( my ($key, $val) = each %{$meta} ) {
# $meta-{$key} = decode(utf8, $val);
# }
The Wide character warning will still appear, but tagging should work.
I'm embarrassed to admit that I should have removed those lines before now.
IIRC, they are a vestigial remnant of my attempts at Perl-only MP4 tagging.
Yep, I can confirm that
Stuart_Maconies_Freakier_Zone_-_08_10_2011_b015gv6n has now completed
the script after commenting out the 3 lines
___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer
[PATCH] Fixes for UTF-8 metadata
This patch addresses problems in get_iplayer 2.80 first reported here:
http://lists.infradead.org/pipermail/get_iplayer/2011-October/002063.html
The patch should prevent this warning:
Wide character in print at get_iplayer.pl line 3530.
This warning is generated when writing an entry containing text encoded
in UTF-8 to the download history file.
The patch should also prevent this error:
Cannot decode string with wide characters at Encode.pm line 162.
(The error location will differ slightly between platforms)
This error is generated by an erroneous attempt to convert to UTF-8 some
text already encoded in UTF-8. This error will prevent MP4/M4A files
from being tagged, though the files should still be playable. My apologies
for the inconvenience.
This patch has been incorporated into the get_iplayer Git repo.
Instructions for updating are here:
https://github.com/dinkypumpkin/get_iplayer/wiki/instructions
PATCH:
1. Added UTF-8 output I/O layer to history file handle (History::add)
2. Removed unnecessary call to Encode::decode (Tagger::tag_metadata)
3. Fixed typo in --tag-utf8 description
---
get_iplayer |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/get_iplayer b/get_iplayer
index 340d005..640c66b 100755
--- a/get_iplayer
+++ b/get_iplayer
@@ -251,7 +251,7 @@ my $opt_format = {
tag_podcast = [ 1, tagpodcast|tag-podcast!, 'Tagging',
'--tag-podcast', Tag downloaded radio and tv programmes as iTunes podcasts
(requires MP3::Tag module for AAC/MP3 files)],
tag_podcast_radio = [ 1, tagpodcastradio|tag-podcast-radio!,
'Tagging', '--tag-podcast-radio', Tag only downloaded radio programmes as
iTunes podcasts (requires MP3::Tag module for AAC/MP3 files)],
tag_podcast_tv = [ 1, tagpodcasttv|tag-podcast-tv!, 'Tagging',
'--tag-podcast-tv', Tag only downloaded tv programmes as iTunes podcasts],
- tag_utf8 = [ 1, tagutf8|tag-utf8!, 'Tagging', '--tag-utf8',
AtomicParsley expects UTF-8 input],
+ tag_utf8 = [ 1, tagutf8|tag-utf8!, 'Tagging', '--tag-utf8',
AtomicParsley accepts UTF-8 input],
# Deprecated
@@ -3520,7 +3520,7 @@ sub add {
return 0 if $opt-{nowrite};
# Add to history
- if ( ! open(HIST, $historyfile) ) {
+ if ( ! open(HIST, :utf8, $historyfile) ) {
main::logger ERROR: Cannot write or append to $historyfile\n;
exit 11;
}
@@ -4282,10 +4282,6 @@ sub tag_metadata {
$meta-{$key} = $val;
}
}
- # expect input in UTF-8
- while ( my ($key, $val) = each %{$meta} ) {
- $meta-{$key} = decode(utf8, $val);
- }
return $meta;
}
--
1.7.7
___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer
Version naming suggestion
With all the incremental changes made by dinkypumpkin (and others) to the 2.80 perl script, I was thinking it might be a good thing to somehow distinguish between them quickly... Perhaps instead of x.yy maybe x.yy-yymmdd ? Just something to make it obvious without having to do a diff/similar. Just a thought. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
RE: Version naming suggestion
With all the incremental changes made by dinkypumpkin (and others) to the 2.80 perl script, I was thinking it might be a good thing to somehow distinguish between them quickly... Hi I think that would be a good feature. Some programs (such as FFmpeg-git) show the 'commit'. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Possible solution to the Windows AtomicParsley crashes?
On 09/10/2011 08:39, Vangelis forthnet wrote: it has pid=p00kdr09. With the workaround suggested, AP (latest binary) tags the m4a file, but only PARTIALLY: The Comment and ©lyr fields (in MediaInfo) contain only the first word of the description, i.e. Were (???). Man, when it rains it pours. It appears that the embedded double quotes in tag values are causing the trouble. This problem is limited to Windows, naturally. I think what's happening is that Perl sees the embedded double quotes as shell metacharacters and hands off AtomicParsley execution to the Windows shell (cmd.exe). In that case, the embedded quotes must be escaped and the parameter value enclosed in an outer pair of double quotes to satisfy cmd.exe quoting rules and preserve the original value. Without the enclosing quotes, only the first word of the parameter value is interpreted as the tag value written to the file, which squares with your results. Maybe someone else with more Win32 Perl-fu can offer a better explanation, but that's what it looks like to me. My inclination is to uniformly convert all embedded double quotes in tag values to single quotes, rather than implement some special handling for Windows. I'll post a patch to do that unless someone can tell me why it's not a good idea. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Version naming suggestion
On 10/09/11 17:13, bat guano wrote: With all the incremental changes made by dinkypumpkin (and others) to the 2.80 perl script, I was thinking it might be a good thing to somehow distinguish between them quickly... Hi I think that would be a good feature. Some programs (such as FFmpeg-git) show the 'commit'. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer Hi, If it is thought there is a need for what is in git then the next release v2.81 should be created. There are only two changes to the get_iplayer script, since v2.80 was tagged in git. The other 4 changes are specific to windows, related to the windows installer. The need for a v2.81 yet may be open to debate. In the past the windows installer has held back the releases of a new versions of get_iplayer. Timely releases replaces any need to invent new version schemes, or end users using other than the released versions. Releases should be made regardless of the windows installer, then should windows fall behind and window users have to resort to getting the get_iplayer script. The version would have been updated for release to other platforms allowing identification by version number. Regards Nigel Taylor ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
AtomicParsley/Win 2.80 tagging changes?
I've been watching the recent AtomicParsley exchanges with some ignorance, but wonder if any of these recent changes has altered the way it tags programmes for the 2.80 update (Windows)? Previously it would concatenate the title as show+episodeID but now I just get episodeID, even tho the show is correctly tagged under video settings For example just prior to my update from 2.79 I got; BBC Weekend News - 08/10/2011 whereas post U/G I get 09/10/2011 which is a little vague can anyone shed any light on this? regards, Andy ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: AtomicParsley/Win 2.80 tagging changes?
On Mon Oct 10 01:11:50 BST 2011, Andy Gascoigne wrote: I've been watching the recent AtomicParsley exchanges with some ignorance, but wonder if any of these recent changes has altered the way it tags programmes for the 2.80 update (Windows)? Previously it would concatenate the title as show+episodeID but now I just get episodeID, even tho the show is correctly tagged under video settings For example just prior to my update from 2.79 I got; BBC Weekend News - 08/10/2011 whereas post U/G I get 09/10/2011 which is a little vague can anyone shed any light on this? Hi, Andy! Version 2.80 of the script has introduced an enhanced tagging pattern to MP4/M4A files, different to the one in v2.79 (and with it came some incompatibilities, that are now in the process of being ironed out - see recent thread: http://lists.infradead.org/pipermail/get_iplayer/2011-October/002063.html). This new pattern makes use of new (2.80 specific) tagging options. Since you are new to 2.80, it is a good thing to generate a copy of the revised long help, by running the command: get_iplayer --helplong [pathway of your choice]\Long Help 2.80.txt and then have a look at it in your spare time, for what's new... In the end of this file lie the new tagging options... Quick reply: To have the title written in a 2.79 manner, just add in your commands this option: --tag-fulltitle If you so wish to make this permanent for all your downloads, add it to your user options by running: get_iplayer --prefs-add --tag-fulltitle Greetings from defaulting Greece, Vangelis. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
