FireFly Media Server › Firefly Media Server Forums › Firefly Media Server › Nightlies Feedback › 20051101 Problems
- This topic has 8 replies, 2 voices, and was last updated 19 years, 1 month ago by rpedde.
-
AuthorPosts
-
10/11/2005 at 6:05 AM #126MikeParticipant
I know some of these have been covered here piecemeal, but here’s my experience with the new nightlies:
-Great work with the playlists, they’re working great. And when I found that ‘experimental’ java applet… that’s damn sexy. That could be a great frontend to streaming files to an Airport device or using mt-daapd as a jukebox with a web frontend.
-Transcoding is totally borked. I’ve been using the same ssc script for successfully since ssc was first introduced. I tried putting in full paths as suggested elsewhere, but it didn’t help. I still can’t listen to my ogg files. The parsing of these files is totally screwed. Most of my ogg files aren’t having their tags parsed any longer (including ones I’m *positive* were getting parsed properly before). I also have one album in particular where the track lengths are totally wrong, but when mt-daapd thinks the track is less than approx one minute long, it’ll play the part it sees (I know that these tracks are much longer than that). For the rest of the tracks, they just plain don’t work. iTunes puts a nice exclamation point by them, although the logs in mt-daapd (at -d 5) suggest that mt-daapd just thinks it’s already sent all of the file:
2005-11-09 17:59:10: Found image file /home/ftp/music/Prefuse 73/[2005] Surrounded by Silence/cover.jpg (fd 12)
2005-11-09 17:59:10: Session 0: Streaming file '19 - Minutes Away Without You.mp3' to 192.168.1.103 (offset 0)
2005-11-09 17:59:10: Found image file /home/ftp/music/Prefuse 73/[2005] Surrounded by Silence/cover.jpg (fd 12)
2005-11-09 17:59:10: Dynamic add artwork to 19 - Minutes Away Without You.mp3 (fd 12)
2005-11-09 17:59:10: Image appears to be 32090 bytes
2005-11-09 17:59:10: Current tag size is 620 bytes
2005-11-09 17:59:10: Done copying IMG 32096
2005-11-09 17:59:11: Finished streaming file to remote: 4386934 bytesSo basically, if it’s ogg, it’s not working. Also, that artwork in the log never showed up.
10/11/2005 at 7:05 AM #3795MikeParticipantA little update… I just downgraded to 20051026 (had to rebuild it), and everything works great. I have my ogg albums back and tagged (this is using the ssc script included with mt-daapd, without modification, so no paths).
I had to delete my existing db, as it was causing mt-daapd grief, but after waiting for it to be rebuilt, everything is working again.
10/11/2005 at 8:09 AM #3796MikeParticipantOkay, so I jumped the gun a little. While ogg tag parsing is working again and most .ogg files are working fine, there are some that are still causing me grief. The ogg files that were no longer having their tags parsed and not being played by 20051101 are now working, but those ogg files that had their tags parsed properly and were not playing properly in 20051101 are still not playing properly in 20051026.
I ran ‘mt-daapd -d 9’, and here’s what I get in the log file:2005-11-09 20:03:10: Thread 3: Entering ws_dispatcher (Connection from 192.168.1.103)
2005-11-09 20:03:10: Thread 3: got request
2005-11-09 20:03:10: Request: GET daap://192.168.1.99:3689/databases/1/items/10516.mp3 HTTP/1.1
2005-11-09 20:03:10: Thread 3: Read: Accept: */*
2005-11-09 20:03:10: Thread 3: Adding header *Accept=*/**
2005-11-09 20:03:10: Added *Accept=*/**
2005-11-09 20:03:10: Thread 3: Read: Cache-Control: no-cache
2005-11-09 20:03:10: Thread 3: Adding header *Cache-Control=no-cache*
2005-11-09 20:03:10: Added *Cache-Control=no-cache*
2005-11-09 20:03:10: Thread 3: Read: User-Agent: iTunes/6.0.1 (Macintosh; N; PPC)
2005-11-09 20:03:10: Thread 3: Adding header *User-Agent=iTunes/6.0.1 (Macintosh; N; PPC)*
2005-11-09 20:03:10: Added *User-Agent=iTunes/6.0.1 (Macintosh; N; PPC)*
2005-11-09 20:03:10: Thread 3: Read: Client-DAAP-Access-Index: 2
2005-11-09 20:03:10: Thread 3: Adding header *Client-DAAP-Access-Index=2*
2005-11-09 20:03:10: Added *Client-DAAP-Access-Index=2*
2005-11-09 20:03:10: Thread 3: Read: Client-DAAP-Validation: 671D443954868AAA67BE30380F15D31A
2005-11-09 20:03:10: Thread 3: Adding header *Client-DAAP-Validation=671D443954868AAA67BE30380F15D31A*
2005-11-09 20:03:10: Added *Client-DAAP-Validation=671D443954868AAA67BE30380F15D31A*
2005-11-09 20:03:10: Thread 3: Read: Client-DAAP-Request-ID: 3
2005-11-09 20:03:10: Thread 3: Adding header *Client-DAAP-Request-ID=3*
2005-11-09 20:03:10: Added *Client-DAAP-Request-ID=3*
2005-11-09 20:03:10: Thread 3: Read: x-audiocast-udpport: 49926
2005-11-09 20:03:10: Thread 3: Adding header *x-audiocast-udpport=49926*
2005-11-09 20:03:10: Added *x-audiocast-udpport=49926*
2005-11-09 20:03:10: Thread 3: Read: icy-metadata: 1
2005-11-09 20:03:10: Thread 3: Adding header *icy-metadata=1*
2005-11-09 20:03:10: Added *icy-metadata=1*
2005-11-09 20:03:10: Thread 3: Read: Connection: close
2005-11-09 20:03:10: Thread 3: Adding header *Connection=close*
2005-11-09 20:03:10: Added *Connection=close*
2005-11-09 20:03:10: Thread 3: Read:
2005-11-09 20:03:10: Thread 3: Headers parsed!
2005-11-09 20:03:10: Checking to see if connection matches close
2005-11-09 20:03:10: And it DOES!
2005-11-09 20:03:10: Thread 3: Connection type HTTP/1.1
: Connection: non-persist
2005-11-09 20:03:10: Thread 3: Original URI: daap://192.168.1.99:3689/databases/1/items/10516.mp3
2005-11-09 20:03:10: Thread 3: Translated URI: /databases/1/items/10516.mp3
2005-11-09 20:03:10: Thread 3: Preparing to find handler
2005-11-09 20:03:10: Thread 3: URI Match!
2005-11-09 20:03:10: Thread 3: Time is 1131584590 seconds after epoch
2005-11-09 20:03:10: Thread 3: Setting time header
2005-11-09 20:03:10: Added *Date=Thu, 10 Nov 2005 01:03:10 GMT*
2005-11-09 20:03:10: Thread 3: Using non-default handler
2005-11-09 20:03:10: Added *Accept-Ranges=bytes*
2005-11-09 20:03:10: Added *DAAP-Server=mt-daapd/cvs-20051026*
2005-11-09 20:03:10: Added *Content-Type=application/x-dmap-tagged*
2005-11-09 20:03:10: Executing: SELECT * FROM songs WHERE id=10516
2005-11-09 20:03:10: Found image file /home/ftp/music/Prefuse 73/[2005] Surrounded by Silence/cover.jpg (fd 12)
2005-11-09 20:03:10: Thread 3: Length of file (remaining) is 987264
2005-11-09 20:03:10: Updating Content-Type from application/x-dmap-tagged to audio/mp3
2005-11-09 20:03:10: Added *Content-Length=987264*
2005-11-09 20:03:10: Added *Connection=Close*
2005-11-09 20:03:10: Emitting reponse header Connection: Close
2005-11-09 20:03:10: Emitting reponse header Content-Length: 987264
2005-11-09 20:03:10: Emitting reponse header Content-Type: audio/mp3
2005-11-09 20:03:10: Emitting reponse header DAAP-Server: mt-daapd/cvs-20051026
2005-11-09 20:03:10: Emitting reponse header Accept-Ranges: bytes
2005-11-09 20:03:10: Emitting reponse header Date: Thu, 10 Nov 2005 01:03:10 GMT
2005-11-09 20:03:10: Entering config_set_status
2005-11-09 20:03:10: Exiting config_set_status
2005-11-09 20:03:10: Session 0: Streaming file ’03 – Bad Memory Interlude One.mp3′ to 192.168.1.103 (offset 0)
2005-11-09 20:03:10: Found image file /home/ftp/music/Prefuse 73/[2005] Surrounded by Silence/cover.jpg (fd 12)
2005-11-09 20:03:10: Dynamic add artwork to 03 – Bad Memory Interlude One.mp3 (fd 12)
2005-11-09 20:03:10: Image appears to be 32090 bytes
2005-11-09 20:03:10: Current tag size is 1578 bytes
2005-11-09 20:03:10: Done copying IMG 32096
2005-11-09 20:03:10: Finished streaming file to remote: 987254 bytes
2005-11-09 20:03:10: Entering config_set_status
2005-11-09 20:03:10: Exiting config_set_status
2005-11-09 20:03:10: Entering config_set_status
2005-11-09 20:03:10: Exiting config_set_status
2005-11-09 20:03:10: Thread 3: Terminating
2005-11-09 20:03:10: Thread 3: Freeing request headers
2005-11-09 20:03:10: Thread 3: Freeing response headers
2005-11-09 20:03:10: Thread 3: Freeing request vars
2005-11-09 20:03:10: Thread 3: Closing fd
2005-11-09 20:03:10: With thread 3 exiting, 1 are still runningThat’s the result when I try and play one of these trouble files. I know for a fact that these files have played in still older nightlies (the august ones worked for sure), so I’m confident that it’s not the files themselves. They have the same owner/permissions as all the rest of my collection, etc.
Anyway, if you need more info or anything, just ask. I grab the rss feed, so I’ll know within the hour ๐10/11/2005 at 12:01 PM #3797rpeddeParticipantTry turning off cover art — see what that does.
10/11/2005 at 3:41 PM #3798MikeParticipantYeah, so that worked. Why is cover art being a problem? Is this a known bug?
11/11/2005 at 12:06 AM #3799rpeddeParticipantWhenever mt-daapd sends the whole file, but iTunes plays it, it’s always an id3v2 tag problem. The cover art stuff basically writes new id3 tags on-the-fly and sends them to iTunes, so that seemed like it might be the problem.
Sure enough.
Now, of course, the question is “why is that broken”, and perhaps even “should that feature even be in mt-daapd?”
11/11/2005 at 4:27 AM #3800MikeParticipantWell, the first question, “why is it broken” I’d be more than happy to help test with you. There’s the -d 9 log output above for you ๐
As for “should it even be in mt-daapd”, well, it certainly doesn’t need to be. But, I’m sure most people will agree, it’d be a pretty slick feature if it worked properly. I mean, that seems to be one of the ways that companies are adding content to cd’s; including lyrics, artwork, etc. Perhaps this isn’t a job for mt-daapd though…11/11/2005 at 8:56 AM #3801rpeddeParticipantYeah, I agree… I *like* it, it’s wickedly cool.
Not so much at the expense of making stuff not work, though. ๐ And besides, it’s easy enough to add the art to the files on the mp3 side… it’s not like the extra disk space is expensive any more.
— Ron
11/11/2005 at 8:57 AM #3802rpeddeParticipantActually, that’s something you could research… can you see what version of id3v2 tags WORK and which version doesn’t?
I’d guess it’s a 2.4 vs 2.3 problem or something like that.
Also, could I talk you into sending a non-working one to ron at pedde.com?
Thanks
— Ron
-
AuthorPosts
- The forum ‘Nightlies Feedback’ is closed to new topics and replies.