PDA

View Full Version : Importing albums with accented characters



cjk32
2006-07-03, 14:25
Hello,

I'm having a problem with 6.5 r8262 when importing the Dire Straits album
Communiqué (accented e). It is showing up as nine separate albums, each
with a single track. As far as I can tell, there appear to be two problems.

Firstly, the test on line 1442 of Schema.pm is failing, meaning that the
album for the second track isn't taken to be the same as the first and so
on. I'm not quite sure why this is happening. It is definitely

$a->get('title') eq $album

that is returning false, although there appears to be no difference in the
two operands. Data::Hexify gives identical output for both:

0000: 43 6f 6d 6d 75 6e 69 71 75 c3 a9 Communiqu..
0000: 43 6f 6d 6d 75 6e 69 71 75 c3 a9 Communiqu..

However, if the 'e acute' is replaced with a plain 'e' in iTunes, the
scanning completes correctly.

This problem however shouldn't be fatal to the scanning process. It is
quite conceivable that the tracks on a single album are not in a contiguous
block, and the scanning process attempts to deal with this by checking the
database to see whether the album already exists. The second problem seems
to be that this too is failing. The SQL statement used to check for an
existing album checks that disc and discc are NULL, rather than checking for
the actual values obtained from the track.

I don’t understand the logic behind line 1473, but I found that changing it
from:

} elsif ($discc && $discc > 1) {

to:

} elsif ($discc && $discc >= 1) {

solved my scanning problems with no side effects.

Chris Key

cjk32
2006-07-05, 06:42
Christopher Key wrote:
> Firstly, the test on line 1442 of Schema.pm is failing, meaning that
> the album for the second track isn't taken to be the same as the
> first and so on.

R8280 fixes this

> This problem however shouldn't be fatal to the scanning process. It
> is quite conceivable that the tracks on a single album are not in a
> contiguous block, and the scanning process attempts to deal with this
> by checking the database to see whether the album already exists.
> The second problem seems to be that this too is failing. The SQL
> statement used to check for an existing album checks that disc and
> discc are NULL, rather than checking for the actual values obtained
> from the track.
>

but this will still I presume present a problem for non-contiguous albums in
iTunes. Should I file a bug report for this?

Chris

Dan Sully
2006-07-05, 07:31
* Christopher Key shaped the electrons to say...

>but this will still I presume present a problem for non-contiguous albums in
>iTunes. Should I file a bug report for this?

What do you mean by "non-contiguous" ?

-D
--
<Daemon> seriously, first there was the circle, then sliced bread, then tivo

cjk32
2006-07-05, 08:22
Dan Sully wrote:
> * Christopher Key shaped the electrons to say...
>
>> but this will still I presume present a problem for non-contiguous
>> albums in iTunes. Should I file a bug report for this?
>
> What do you mean by "non-contiguous" ?

Where the tracks for one album are non all stored together in the iTunes xml
file. For example, consider albums A and B, each with tracks 1-3, being
stored in the order A1, A2, B1, B2, B3, A3.

However, having done some further testing, I was misunderstanding what
exactly was going on on line 1448. The tracks do all appear to add
correctly even if non contiguous. I still don't understand the logic behind
lines 1477 to 1489, specifically why a match on discc is only attempted if
discc > 1, otherwise a match is attempted for disc and discc both NULL.

Chris

Dan Sully
2006-07-05, 08:44
* Christopher Key shaped the electrons to say...

>However, having done some further testing, I was misunderstanding what
>exactly was going on on line 1448. The tracks do all appear to add
>correctly even if non contiguous. I still don't understand the logic behind
>lines 1477 to 1489, specifically why a match on discc is only attempted if
>discc > 1, otherwise a match is attempted for disc and discc both NULL.

Often (bug 3662), people don't add a DISCC value to their music.

The other case, bug: 3254 - a user had:

AC/DC - Live
AC/DC - Live (Disc 1 of 2)
AC/DC - Live (Disc 2 of 2)

So one is defeated on any title matching alone because it's a common title,
and two, because of an album of the same name by the same artist but with
different disc & discc values.

-D
--
Sir, are you classified as human?
Uhh, negative, I am a meat popsicle.

Dan Sully
2006-07-05, 09:02
* Christopher Key shaped the electrons to say...

>Ok, maybe I'm still missing something. It just seems a bit strange to
>attempt to match discc if a user has set discc = 2,3,4 etc. but to search
>for 'disc is NULL AND discc is NULL' if the user has set discc = 1.
>Likewise, it seemed a bit strange to search for 'disc is NULL AND discc is
>NULL' if discc hadn't been set, regardless of what the user has set for
>disc.

It's not.. the search for discc is NULL is only set if there is no disc or discc.

$search->{'disc'} = undef if !defined $disc;
$search->{'discc'} = undef if !defined $disc && !defined $discc;

-D
--
"It has become appallingly obvious that our technology has exceeded our humanity." - Albert Einstein