›

Base de données iTunes non modifiable ?

SystemSystem
06:57 modifié dans API AppKit #1
Bonjour à  tous,

Je cherche à  modifier la base de données iTunes. Pas de grosses modifications, simplement modifier, par exemple, la note d'un morceau et son play count à  partir du XML "iTunes Music Library.xml"
Le problème c'est que la modification n'est jamais prise en compte.

Vous pouvez testez vous meme, quittez iTunes, ouvrez le XML avec Property List Editor, prenez un morceau au hasard dans "Tracks" et modifier son "Rating" (5 étoiles = 100, 1 étoile = 20). Mettez donc une note différente de l'actuelle, sauvegardez le fichier.
Relancez iTunes et allez rechercher votre track modifié.. la note reste la meme..
Si vous vous amusez à  quitter/relancer, le XML gardera la nouvelle note que vous lui aviez donné.. Mais dès que vous lancez une lecture dans iTunes (ou que vous switchez de playlist aussi, je pense), le XML sera modifié et le track aura retrouvé sa note d'origine.

J'ai cherché tous les caches possibles, en vain..

Alors.. mystère et boule de gomme.. Il n'y a plus qu'à  espérer que ça ne soit pas la faute à  "iTunes Library", car je pense que c'est indécodable comme fichier..


Louka.

Réponses

  • AliGatorAliGator Membre, Modérateur
    06:57 modifié #2
    Pour t'aider à  fouiller, j'ai lancé fseventer (si tu connais pas c'est un soft qui monitor les fsevents via l'API de Leopard permettant d'écouters tous les events du filesystem). J'ai lancé iTunes, puis l'enregistrement des fsevents, et changé la note d'un de mes morceaux dans iTunes, et voilà  ce que ça donne comme graphe, ainsi que le détail des fichiers créés/modifiés/supprimés.

    Sachant que les fichiers temporaires ("Temp File.tmp" et "cfx#tJFaYiP") sont à  mon avis clairement en fait la traduction d'une modification des fichiers qui sont à  côté d'eux ("iTunes Library" et "iTunes Music Library.xml" pour le premier, "com.apple.iApps.plist" pour le second) par un "writeToFile:... atomically:YES" (le "atomically:YES" ayant pour effet, pour rappel, justement d'écrire dans un fichier temporaire et de remplacer l'original par ce fichier temporaire une fois prêt, plutôt que d'écrire direct dans le fichier original)

    Conclusion, quand on change la note d'un morceau, il n'y à  a priori pas 36 fichiers modifiés en conséquence, juste :
    - le fichier de préférences (et encore c'est sans doute pour indiquer la dernière piste sélectionnée dans iTunes un truc comme ça)
    - le "iTunes Music Library.xml"...
    - ... et le fichier "iTunes Library" justement, celui que tu craignais  ::)

    Désolé :P
  • SystemSystem
    06:57 modifié #3
    En effet... j'ai viré le XML, lancé iTunes, et mes musiques étaient quand meme là ..
    Il n'y a vraiment aucun moyen de décoder ce fichier "iTunes Library" ?
  • AliGatorAliGator Membre, Modérateur
    06:57 modifié #4
    ... et un peu d'AppleScript/AppleEvents pour piloter iTunes ?
  • SystemSystem
    06:57 modifié #5
    dans 1239395259:

    ... et un peu d'AppleScript/AppleEvents pour piloter iTunes ?

    Bha c'est justement ce que je cherche à  éviter...
  • schlumschlum Membre
    avril 2009 modifié #6
    Ben bon courage si tu cherchez à  bidouiller ça...  :o

    Dans le cadre de mon boulot, j'ai bossé avec un driver qu'on a développé plus puissant que fsevents, qui donne non seulement les fichiers modifiés, mais aussi les zones de modification...
    Je peux essayer de faire un peu de reverse engineering, mais à  mon avis c'est carrément complexe (surtout si plein de choses sont modifiées en mémoire avant la bufferisation dans le fichier).
  • SystemSystem
    06:57 modifié #7
    dans 1239404936:

    Ben bon courage si tu cherchez à  bidouiller ça...  :o

    Dans le cadre de mon boulot, j'ai bossé avec un driver qu'on a développé plus puissant que fsevents, qui donne non seulement les fichiers modifiés, mais aussi les zones de modification...
    Je peux essayer de faire un peu de reverse engeneering, mais à  mon avis c'est carrément complexe (surtout si plein de choses sont modifiées en mémoire avant la bufferisation dans le fichier).


    Bha si jamais tu trouves quelque chose  :o pourquoi pas. Mais c'est vrai que si c'est compliqué... d'un côté j'espère que ça sera pas trop gênant pour mon application de ne pas pouvoir noter et garder à  jour les smart playlists (grâce à  la date de dernière écoute & nombre d'écoutes par exemple)... après c'est vrai que je peux toujours m'en servir en AppleScript si jamais l'utilisateur a lancé iTunes.. mais bon c'est vraiment pas top..

    Le top du top ça serait que le fichier iTunes Library soit pas trop compliqué à  manipuler  :fouf):
  • schlumschlum Membre
    06:57 modifié #8
    Bizarre, chez moi c'est du XML classique...

    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;8224&lt;/key&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;dict&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Track ID&lt;/key&gt;&lt;integer&gt;8224&lt;/integer&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Name&lt;/key&gt;&lt;string&gt;Piste 01&lt;/string&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Artist&lt;/key&gt;&lt;string&gt;Vivaldi A.&lt;/string&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Album&lt;/key&gt;&lt;string&gt;mandolines allegro1&lt;/string&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Genre&lt;/key&gt;&lt;string&gt;Adagio&lt;/string&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Kind&lt;/key&gt;&lt;string&gt;Fichier audio MPEG&lt;/string&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Size&lt;/key&gt;&lt;integer&gt;5639126&lt;/integer&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Total Time&lt;/key&gt;&lt;integer&gt;281835&lt;/integer&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Track Number&lt;/key&gt;&lt;integer&gt;1&lt;/integer&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Track Count&lt;/key&gt;&lt;integer&gt;18&lt;/integer&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Date Modified&lt;/key&gt;&lt;date&gt;2008-06-08T01:08:51Z&lt;/date&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Date Added&lt;/key&gt;&lt;date&gt;2004-11-25T20:19:03Z&lt;/date&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Bit Rate&lt;/key&gt;&lt;integer&gt;160&lt;/integer&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Sample Rate&lt;/key&gt;&lt;integer&gt;44100&lt;/integer&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Play Count&lt;/key&gt;&lt;integer&gt;2&lt;/integer&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Play Date&lt;/key&gt;&lt;integer&gt;3185547796&lt;/integer&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Play Date UTC&lt;/key&gt;&lt;date&gt;2004-12-10T16:23:16Z&lt;/date&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Rating&lt;/key&gt;&lt;integer&gt;60&lt;/integer&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Album Rating&lt;/key&gt;&lt;integer&gt;60&lt;/integer&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Album Rating Computed&lt;/key&gt;&lt;true/&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Persistent ID&lt;/key&gt;&lt;string&gt;F545BB1624339F76&lt;/string&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Track Type&lt;/key&gt;&lt;string&gt;File&lt;/string&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;File Type&lt;/key&gt;&lt;integer&gt;1297106739&lt;/integer&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;File Creator&lt;/key&gt;&lt;integer&gt;1752133483&lt;/integer&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Location&lt;/key&gt;&lt;string&gt;file://localhost/Volumes/HD/iTunes%20Music/Vivaldi%20A_/mandolines%20allegro1/01%20Piste%2001.mp3&lt;/string&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;File Folder Count&lt;/key&gt;&lt;integer&gt;4&lt;/integer&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;key&gt;Library Folder Count&lt;/key&gt;&lt;integer&gt;1&lt;/integer&gt;<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/dict&gt;


    Vous êtes sûrs que c'est pas simplement du XML-binaire chez vous ?
  • SystemSystem
    06:57 modifié #9
    Tu as ouvert quoi ? iTunes Library ou iTunes Music Library.xml ?
    Le iTunes Music Library.xml c'est en effet du simple XML, mais l'autre j'ai beau l'ouvrir avec TextEdit je vois que des caractères pourris. PLE ne veut meme pas l'ouvrir.
  • schlumschlum Membre
    06:57 modifié #10
    Le .xml... Mais effectivement, il ne suffit peut-être pas de modifier que celui-là .
  • schlumschlum Membre
    06:57 modifié #11
    Pour le non XML, quelqu'un a déjà  fait du Reverse engineering dessus apparemment :
    http://search.cpan.org/~bdfoy/Mac-iTunes-0.90/doc/file_format.pod
  • SystemSystem
    06:57 modifié #12
    dans 1239411277:

    Pour le non XML, quelqu'un a déjà  fait du Reverse engineering dessus apparemment :
    http://search.cpan.org/~bdfoy/Mac-iTunes-0.90/doc/file_format.pod


    'vache  :-\\ c'est mort pour moi ce genre de truc :D
  • schlumschlum Membre
    06:57 modifié #13
    Ben j'espère que tu veux pas bosser dans l'informatique alors parce que ce genre de trucs c'est de la base une fois qu'on a les spécifications  :P J'en ai encore écrit un il y a quelques semaines...
  • SystemSystem
    06:57 modifié #14
    dans 1239443242:

    Ben j'espère que tu veux pas bosser dans l'informatique alors parce que ce genre de trucs c'est de la base une fois qu'on a les spécifications  :P J'en ai encore écrit un il y a quelques semaines...

    Ouaip enfin ça c'est de l'informatique profond pour moi  ;D Je suis plus à  l'aise sur du code de base avec une joli interface que le côté cambouis.
    'fin là  pour moi y'a rien niveau documentation...
  • AliGatorAliGator Membre, Modérateur
    avril 2009 modifié #15
    Je t'ai fait un petit exemple sans prétention d'un parseur de fichiers de ce type. Ce format de fichier dans son ensemble est assez répandu en fait (composition d'un fichier en "blocs", chaque bloc étant décrit par un code FOURCC de 4 lettres, suivi de la longueur du bloc, puis de ses données dont le format dépend du code FOURCC), tant pour le format RIFF utilisé pour les fichiers WAV ou AVI que pour l'AIFF ou le MPEG ou le MOV et j'en passe.
    Après ce qui diffère pour chaque format de fichier ce sont les codes FOURCC et la structure des données dans ces blocs (en bref, les types de blocs utilisés qui changent quoi)

    Bon ceci étant dit, mon petit bout de code parse le premier bloc, de type "hdfm", et affiche la "Version String" (en l'occurence "8.1.1" chez moi)... mais ensuite il tombe sur 4 octets (sensés être le code FOURCC du bloc suivant) qui sont en fait "B0 11 AC EB" en hexa... ce qui n'a rien d'un des FOURCC référencés...
    J'ai regardé dans le hexdump du fichier iTunes Library, ce sont en effet ces octets qui sont présents à  cet endroit... et je ne trouve aucun truc ressemblant à  un FOURCC dans les alentours, donc je sais pas trop ce qui se passe... soit mon code est foireux (sur la lecture de la longueur du bloc par exemple ? Si je swap pas mes bits sur les octets de longueur c'est pas mieux donc je vois pas), soit y'a une subtilité dans le format qui est apparue depuis (par exemple les bits lus dans "unknown1" sont en fait des flags dont l'un deux indique que tout le reste du fichier est gzippé ou je ne sais quoi...)

    Du coup mon programme ne va pas bcp plus loin que la lecture du premier bloc, et après bah faut voir ce qui cloche. Mais bon ça te donne une idée comme quoi le code pour parser ce genre de fichier est pas bien méchant.

    D'autant qu'il y a plein de petites astuces en C, comme la notation 'hdim' entre apostrophes qui est une notation possible pour un "unsigned long" en définissant ses 4 octets avec le code ascii des caractères donnés (exactement sur le même principe que 'A' définit la valeur 65 d'un unsigned char), ce qui permet ensuite par exemple de faire un "switch(fourcc.code) { case 'hdfm': ... case 'hdim': .... }" etc.

    Ou encore la possibilité de lire des données directement dans une structure C... En effet pour le bloc "hdfm" j'ai parsé le bloc champ par champ (en particulier parce que le champ "version string" est de longueur variable et que le nombre de caractères à  lire est à  lire juste avant)... Mais bien souvent (par exemple pour htim) tu peux lire tout plein de champs en une seule passe (avec un seul fread) en utilisant une structure C (struct htim_block { ... }) et en la lisant d'un bloc... Tu as alors juste après le fread directement tes valeurs répartis dans les différents champs de ta structure, sans rien d'autre à  faire, et tu peux directement accéder à  "htim.rating" par exemple...

    Bref au final le code n'est pas sorcier, c'est le retro-engineering qui prend juste un peu plus de temps ;)
  • SystemSystem
    06:57 modifié #16
    Ouarf merci ! Je vais voir tout ça attentivement quand j'aurai résolu un autre problème bien bizarre
  • schlumschlum Membre
    06:57 modifié #17
    dans 1239526793:

    'fin là  pour moi y'a rien niveau documentation...


    Tu rigoles ? C'est une spec tout ce qu'il y a de plus documentée  ;) La personne a plutôt fait du beau travail je trouve...
  • SystemSystem
    06:57 modifié #18
    dans 1239617196:

    dans 1239526793:

    'fin là  pour moi y'a rien niveau documentation...


    Tu rigoles ? C'est une spec tout ce qu'il y a de plus documentée  ;) La personne a plutôt fait du beau travail je trouve...


    Ouaip enfin tout le monde n'a pas ton niveau non plus...
  • schlumschlum Membre
    06:57 modifié #19
    Bah, c'est pas une question de niveau... Lire un buffer (il faut juste faire gaffe aux problèmes endianness... pour la taille surtout, c'est peut-être le problème d'Ali (?) ), c'est pas d'un niveau algorithmique de folie hein  :P

    Le problème surtout, c'est que comme c'est un format propriétaire, c'est sujet à  changer sans aucun avertissement.
  • SystemSystem
    06:57 modifié #20
    dans 1239622317:

    Bah, c'est pas une question de niveau... Lire un buffer (il faut juste faire gaffe aux problèmes endianness... pour la taille surtout, c'est peut-être le problème d'Ali (?) ), c'est pas d'un niveau algorithmique de folie hein  :P

    Le problème surtout, c'est que comme c'est un format propriétaire, c'est sujet à  changer sans aucun avertissement.


    Le truc c'est que pour moi c'est du cambouis et j'aime pas :D

    Par contre j'aime bien être malin :


    if the ITL file is corrupted or damaged, then iTunes will revert to the XML file in order to rebuild it (and consequently, your library data). So the plan is to edit the XML file to reflect the changes in our file paths, and somehow damage the ITL file in order to get iTunes to rebuild it from our revised XML file. If this sounded a bit complicated, worry not"we describe the actions needed step-by-step below:
    Quit iTunes.
    Backup your iTunes Music folder"this contains your library data. Now that it's relieved from your podcasts and iTunes rips it's considerably lighter too, so do an additional backup or two just to be on the safe side. Do this. Now.
    Move your music files (those indexed by iTunes that are neither iTunes podcasts nor iTunes rips) from the old location (say, C:Documents and SettingsUsernameMy DocumentsMy MusicNon-iTunes) to the new location (say, D:MusicNon-iTunes).
    Open the "iTunes Library.itl" file. Select all text (Ctrl+A) and delete it. The file is now blank, with zero characters on it"save it. iTunes Library.itl's filesize should now be 0 bytes. (This is important, as Schmolle notes, because some unicode aware editors"e.g. UltraEdit"may add invisible characters to the beginning of the file.)
    Open the "iTunes Music Library.xml" and do a global search and replace with your text editor of choice. A screenshot of how this is done in EditPad Lite, a freeware text editor that's light and powerful follows after the end of this list.
    Save the XML file.
    Launch iTunes. A prompt with a progress bar will come up"iTunes is rebuilding your library. Depending on how powerful your computer is and the size of your music library, this may take a while. When this ends, iTunes will come up with a message saying that the library file was corrupted/damaged and it tried to rebuild things for you. Press “OK”, iTunes finally launches.
    Check to see if all your music and playlists are there, and if library data (play counts, etc.) has been preserved. (Hopefully everything's fine.) You'll also notice a couple of additional static playlists for your podcasts, videos, etc.
  • NoNo Membre
    06:57 modifié #21
    Tu te rends compte de ce que t'es en train d'écrire ?
    Tu es prêt à  endommager un fichier ne t'appartenant pas (celui d'itunes)...

    Et que ce passera t'il si la "reconstruction" ne fonctionne pas ?
    Ou si Apple décide que dans la prochaine sous-version d'iTunes, il n'y aura plus de mécanisme de reconstruction ?

    Eh bien j'aurai un iTunes vide, tout ça parce j'aurai fait confiance à  un développeur un peu inconscient en installant un truc pas propre sur mon système.
  • SystemSystem
    avril 2009 modifié #22
    dans 1239623785:

    Tu te rends compte de ce que t'es en train d'écrire ?
    Tu es prêt à  endommager un fichier ne t'appartenant pas (celui d'itunes)...

    Et que ce passera t'il si la "reconstruction" ne fonctionne pas ?
    Ou si Apple décide que dans la prochaine sous-version d'iTunes, il n'y aura plus de mécanisme de reconstruction ?

    Eh bien j'aurai un iTunes vide, tout ça parce j'aurai fait confiance à  un développeur un peu inconscient en installant un truc pas propre sur mon système.


    Enfin en meme temps dans les deux cas c'est risqué.. Et dans les deux cas la sauvegarde est toujours possible.
    De toute façon je compte pas utiliser la 2eme méthode puisque ça met un certain temps à  être reconstitué.
    Vais devoir me mettre à  Applescripter iTunes et basta  :adios!:

    (Quoi que je vais quand meme me pencher sur la solution proposée par Schlum/Ali)
  • schlumschlum Membre
    06:57 modifié #23
    dans 1239622970:

    Par contre j'aime bien être malin

    [...]


    Oui, je me doutais qu'il en reconstruisait un avec l'autre... Mais à  mon avis ça met du temps avec une grosse bibliothèque...
    Si les mecs qui utilisent ton logiciel voient leur base se reconstruire à  chaque notation ils risque de faire une drôle de tête.
    Puis si l'autre se corrompt, hop on perd tout, chouette  :adios!:

    --> Pas malin du tout  :P
  • schlumschlum Membre
    06:57 modifié #24
    Puis je pense que c'est valable dans l'autre sens... Si le XML est corrompu il doit le reconstruire à  partir du fichier. C'est une double couverture qu'il ne faut pas bidouiller.
    Ils ont dû faire ça justement pour les gens perdant leur bibliothèque...
  • schlumschlum Membre
    06:57 modifié #25
    Puis je crois que t'as pas tout lu  :P

    Launch iTunes. A prompt with a progress bar will come up"iTunes is rebuilding your library. Depending on how powerful your computer is and the size of your music library, this may take a while. When this ends, iTunes will come up with a message saying that the library file was corrupted/damaged and it tried to rebuild things for you. Press “OK”, iTunes finally launches.
    Check to see if all your music and playlists are there, and if library data (play counts, etc.) has been preserved. (Hopefully everything's fine.) You'll also notice a couple of additional static playlists for your podcasts, videos, etc.


    T'as vraiment envie que les gens aient un message " votre base a été corrompue " à  chaque fois qu'ils utilisent ton add-on ?  :P
  • SystemSystem
    06:57 modifié #26
    dans 1239625232:

    Puis je pense que c'est valable dans l'autre sens... Si le XML est corrompu il doit le reconstruire à  partir du fichier. C'est une double couverture qu'il ne faut pas bidouiller.

    à  vrai dire, tu peux t'amuser à  supprimer le XML.. il ne s'en sert pas du tout.. comme tu dis ça doit être un moyen de reconstruire le iTunes Library si jamais il est corrompu.. mais ça me semble bizarre de stocker cette couverture XML juste à  côté du fichier... Pourquoi pas dans un endroit isolé voir meme en fichier caché. Je me demande plutôt si Apple ne laisse pas non plus ce XML pour les applications tierces en fait.
    Si le XML est supprimé, iTunes ne bronchera pas du tout et le construira en meme pas 1 seconde à  partir du moment où tu modifie une playlist, ou une chanson, ou meme simplement quand tu lances une bête lecture.


    (Sisi j'avais tout lu :p mais de toute façon c'est nul comme méthode)
  • AliGatorAliGator Membre, Modérateur
    06:57 modifié #27
    dans 1239622317:

    Bah, c'est pas une question de niveau... Lire un buffer (il faut juste faire gaffe aux problèmes endianness... pour la taille surtout, c'est peut-être le problème d'Ali (?) ), c'est pas d'un niveau algorithmique de folie hein  :P
    Carrément, franchement, quand on voit certaines RFC parfois alambiquées... ici le format tel que le gars le décrit est vraiment simple et sa page est propre, si tu n'arrives pas à  lire ce genre de spec c'est que tu ne fais pas d'effort :)

    Et non ce n'est pas un problème d'endianness schlum, j'y avais pensé, tu penses, moi aussi suis un habitué de ce genre de parsing ^^ Mais comme dit dans mon post précédent, j'ai essayé avec et sans swapper mes bytes, et dans les 2 cas j'ai un souci.
    - Les octets indiquant la longueur sont juste 0x90000000
    - Donc soit je lis une longueur de bloc "hdfm" de 144 octets (0x90), mais quand je regarde ensuite 144-8 octets plus tard (moins 8 car j'ai déjà  lu le FOURCC = 4 octets et le unsigned long = 4 octets indiquant ladite longueur de bloc) je tombe sur les octets cités B0 11 AC EB qui ne correspondent à  aucun FourCC (et même quand je regarde les octets voisins dans le hexdump du fichier y'a rien qui y ressemble, au cas où j'aurais eu un petit décalage)
    - Soit j'interprète la longueur en bigendian et ça me donne une longueur de bloc dans les 2 milliards, pas très probant...
  • schlumschlum Membre
    06:57 modifié #28
    Ah oui, j'avais raté le p'tit commentaire sur le swap  ;)
    Peut-être que le format a évolué depuis le reverse engineering que j'ai trouvé...  :(
    Le plus gros problème avec ce genre de trucs c'est qu'on n'est jamais à  l'abri d'un changement des specs.
  • damdamdamdam Membre
    06:57 modifié #29
    dans 1239560824:

    J'ai regardé dans le hexdump du fichier iTunes Library, ce sont en effet ces octets qui sont présents à  cet endroit... et je ne trouve aucun truc ressemblant à  un FOURCC dans les alentours, donc je sais pas trop ce qui se passe... soit mon code est foireux (sur la lecture de la longueur du bloc par exemple ? Si je swap pas mes bits sur les octets de longueur c'est pas mieux donc je vois pas), soit y'a une subtilité dans le format qui est apparue depuis (par exemple les bits lus dans "unknown1" sont en fait des flags dont l'un deux indique que tout le reste du fichier est gzippé ou je ne sais quoi...)




    Cette analyse est tout à  fait exacte. Mais le format binaire de iTunes DB a changé entre la version 3 et 4. A partir de la version 4, tout est crypté par un moyen que je n'ai pas réussi à  découvrir (j'ai trouvé la porte secrète, tapé dessus, ça sonne creux, mais j'ai pas trouvé sur quelle pierre appuyer). A ma connaissance, ce format est toujours un mystère. Personne n'a trouvé comme le parser correctement.
Connectez-vous ou Inscrivez-vous pour répondre.