FreeBSD, SMB-shares en ID3v2-tags

Pagina: 1
Acties:

  • Demo
  • Registratie: Juni 2000
  • Laatst online: 29-01 13:56

Demo

Probleemschietende Tovenaar

Topicstarter
Mijn topictitel roept in eerste instantie wellicht wat vraagtekens op. Toch zijn dit precies de kernwoorden van een probleem waar ik momenteel tegenaan loop. Ik ben bezig om een oude thinclient om te bouwen tot netwerk mp3-speler en gebruik hiervoor FreeBSD met wat software, waaronder Music Player Daemon.
De mp3's staan op mijn Windows-PC en worden geshared en onder FreeBSD gemount met smbfs. Werkt inmiddels allemaal best leuk, behalve de ID3-tags van de mp3's. Zowel musicpd als scmpc (Last.fm client) geven deze niet weer. Tags in FLAC-audiobestanden worden wel goed herkend.
In eerste instantie dacht ik dat dit te maken had met de charset die voor de tags gebruikt was. Dus wat zitten stoeien met ID3v2.4 UTF-8, ID3v2.3 UTF-16 en ID3v2.3 ISO-8859-1, maar dat gaf geen resultaat.
Nou zat ik vandaag wat te rotzooien met mp3's op mijn server, die ook FreeBSD draait. Tot mijn grote verbazing, werden vanaf die share de ID3-tags wel weergegeven - van exact dezelfde mp3 als ook op mijn Windows-machine staat. Na wat testen blijkt zelfs, dat als ik een mp3 kopieer van /music (waar de Windows-share op gemount is) naar /tmp (ramdisk op de thinclient) dan kan ik van de ene de ID3 niet lezen en van de andere wel?! Ik heb voor de zekerheid een MD5-hash van beide bestanden gedaan, maar die is exact hetzelfde.
Terwijl ik dit zit te tikken, probeer ik even een symlink te maken in /tmp, naar het bestand in /music en dan worden de tags ook gewoon uitgelezen :? Heeft iemand enig idee waar dit mee te maken zou kunnen hebben? Ik ben momenteel het spoor compleet bijster :P

Unix doesn't prevent a user from doing stupid things, because that would necessarily prevent them from doing brilliant things.
while true ; do echo -n "bla" ; sleep 1 ; done


  • deadinspace
  • Registratie: Juni 2001
  • Laatst online: 23:23

deadinspace

The what goes where now?

Woei, dat is een interessant probleem :P

Heb je het al met de command-line id3v2 tool geprobeerd?
Dus
id3v2 -l /music/muziekje.mp3
id3v2 -l /tmp/muziekje.mp3


Vertoont die hetzelfde gedrag als musicpd en scmpc?

  • blorf
  • Registratie: December 2003
  • Laatst online: 25-12-2025
Dus als ik het goed begrijp:

Als je het bestand "download" van je windows-bak kun je de id3 tags wel lezen, maar als je het bestand rechtsstreeks vanuit de windows share opent met een player dan zie je niks.

probeer eens een mp3tje in /music te openen met een hex-editor. Dan moet je de tags redelijk kunnen lezen.

You are in a maze of little twisting passages, all different.


  • Demo
  • Registratie: Juni 2000
  • Laatst online: 29-01 13:56

Demo

Probleemschietende Tovenaar

Topicstarter
OK, ik ben een prutser!
Aangezien ik vanaf een CF-kaart werk is mijn filesystem read-only en /tmp en /var zijn memdisks. Musicpd maakt gebruik van een database om de muziek te indexeren en aangezien ik die moet kunnen schrijven, heb ik een scriptje gefabriceerd dat de db bij het opstarten van de CF-kaart naar /var/db kopieert en bij het afsluiten de partitie als rw mount en de db weer bewaart. (elke keer bij het booten de db vullen duurde nogal lang)
Ik heb zojuist ontdekt dat cp de owner van een bestand verandert naar diegene die het bestand kopieert, root dus. (heb dit in een ver verleden wel eens gelezen) Hierdoor had musicpd geen schrijfrechten op de db en blijkbaar is er bij de eerste keer vullen van de db iets fout gegaan, waardoor de ID3's niet opgeslagen waren. De FLAC's die ik geprobeerd heb waren later pas op de share gegooid en stonden dus nog niet in de database, daardoor werden die wel goed weergegeven. En scmpc die leest zijn info uit vanuit musicpd, dus als die niks heeft dan ziet scmpc ook niets:P

Unix doesn't prevent a user from doing stupid things, because that would necessarily prevent them from doing brilliant things.
while true ; do echo -n "bla" ; sleep 1 ; done