Ticket #49 (closed defect: fixed)

Opened 3 years ago

Last modified 2 years ago

Doesn't encode UTF-8 HTOA track name properly

Reported by: http://lool.myopenid.com/ Owned by: https://thomasvs.myopenid.com/
Priority: major Milestone: 0.1.2
Component: morituri Version: master
Keywords: patch Cc:

Description

Hey

the encore() dance is also needed in the case of the HTOA track

will attach patch

Cheers,

Attachments

1001_fix-non-ascii-htoa.patch Download (860 bytes) - added by http://lool.myopenid.com/ 3 years ago.
Fix encoding of non-ASCII HTOA track in .m3u
1004_fix-non-ascii-date.patch Download (780 bytes) - added by http://lool.myopenid.com/ 3 years ago.
Fix encoding of non-ASCII dates in log file

Change History

Changed 3 years ago by http://lool.myopenid.com/

Fix encoding of non-ASCII HTOA track in .m3u

comment:1 Changed 3 years ago by https://thomasvs.myopenid.com/

Thanks for the patch, looks good.

I have to wonder though - since the HTOA naming is decided internally, how did you get non-ASCII chars in there ?

comment:2 Changed 3 years ago by http://lool.myopenid.com/

This happened when encoding the High Heels soundtrack which is from a Japanese composer: 坂本龍一 - High Heels (Tacones Lejanos)

I'm not entirely sure where the album name was used, but it seems to be more than just 8-bit chars since I had encoded "Le Fabuleux Destin d'Amélie Poulain" earlier, and didn't get this problem.

PS: sorry for the slow response, I need to figure out how to get email updates with the openid auth I'm using

comment:3 Changed 3 years ago by http://lool.myopenid.com/

Oh sorry, there was no HTOA track on "Le Fabuleux Destin d'Amélie Poulain", so I guess it's just a combination of presence of HTOA track + UTF-8 album name.

I just got a similar error on another album, albeit at a different place:
Traceback (most recent call last):

File "/usr/bin/rip", line 35, in <module>

sys.exit(main.main(sys.argv[1:]))

File "/usr/lib/python2.6/dist-packages/morituri/rip/main.py", line 12, in main

ret = c.parse(argv)

File "/usr/lib/python2.6/dist-packages/morituri/extern/command/command.py", line 329, in parse

return self.subCommands[command].parse(args[1:])

File "/usr/lib/python2.6/dist-packages/morituri/extern/command/command.py", line 329, in parse

return self.subCommands[command].parse(args[1:])

File "/usr/lib/python2.6/dist-packages/morituri/extern/command/command.py", line 300, in parse

ret = self.do(args)

File "/usr/lib/python2.6/dist-packages/morituri/rip/cd.py", line 290, in do

prog.writeLog(discName, logger)

File "/usr/lib/python2.6/dist-packages/morituri/common/program.py", line 599, in writeLog

handle.write(logger.log(self.result).encode('utf-8'))

File "/usr/lib/python2.6/dist-packages/morituri/result/logger.py", line 32, in log

return '\n'.join(lines)

UnicodeDecodeError?: 'ascii' codec can't decode byte 0xc3 in position 21: ordinal not in range(128)

I think it's just because we're now in December ("décembre" in French), and so this might not be an unicode():

date = time.strftime("%b %d %H:%M:%S", time.localtime(epoch))

I think one needs to import locale and convert the date output from locale encoding into an unicode object with:

date = unicode(date, locale.getpreferredencoding())

will attach patch

Changed 3 years ago by http://lool.myopenid.com/

Fix encoding of non-ASCII dates in log file

comment:4 Changed 2 years ago by http://thomasvs.myopenid.com/

  • Keywords patch added

comment:5 Changed 2 years ago by http://thomasvs.myopenid.com/

Commited a fix for the date problem in [450] - I prefer to write it in the C locale instead since that whole file is not localized.

comment:6 Changed 2 years ago by http://thomasvs.myopenid.com/

  • Status changed from new to closed
  • Resolution set to fixed

It seems I had already fixed this independently in [404] and #25. Closing.

Note: See TracTickets for help on using tickets.