FireFly Media Server › Firefly Media Server Forums › Firefly Media Server › Add-on Software › Developers: Crashing firefly by issueing parallell queries?
- This topic has 8 replies, 4 voices, and was last updated 16 years, 4 months ago by EVILRipper.
-
AuthorPosts
-
24/07/2008 at 3:29 PM #2575gurgel2Participant
Im developing a player for personal use (and more even). One issue ive stumbled upon is that when issueing parallell queries to firefly, I easily make it crash. That or, it might be that I interrupt receival of ongoing queries, to start a new one. Dont really know as I just use the .NET/WPF framwork to issue these queries – dont exactly know the mechanics of gui worker threads . What is happing in the background so to speak.
Is this something other developers have encountered? What rules should you obey?
24/07/2008 at 4:09 PM #17497EVILRipperParticipantUm. I’d love to answer. But I don’t know how you’re ‘talking’ to firefly.
Are you using DAAP/RSP requests using URL? Or have you found a way to connect to sqlite directly?And give an example which calls/requests you are running, maybe those are the ones killing firefly.
24/07/2008 at 5:47 PM #17498gurgel2Participant@EVILRipper wrote:
Um. I’d love to answer. But I don’t know how you’re ‘talking’ to firefly.
Are you using DAAP/RSP requests using URL? Or have you found a way to connect to sqlite directly?And give an example which calls/requests you are running, maybe those are the ones killing firefly.
I Use daap i presume (what is described in http://wiki.mt-daapd.org/wiki/XML_Client_API)
When googling on RSP (roku/firefly) i didnt find any reference manuals, do you have one? Is it preferable to use that over daap?
I use queries described in the above mentioned url.. AND they do work when really letting them finish before issuing another one. I dont know if the request/response process is able to finish or is terminated when issueing another one in the gui… id presume they would be queued.. maybe executed in parallell… but I have to check this.
Is this something you have seen?
25/07/2008 at 7:57 AM #17499fizzeParticipantSqlite2 is iffy in some environments. Make sure you use sqlite3.
25/07/2008 at 9:33 AM #17500EVILRipperParticipanthttp://forums.fireflymediaserver.org/viewtopic.php?t=7968
In the above topic I described the difference between DAAP and RSP.I created the DaapPlaylistGenerator app from this forum. In that, I didn’t use the XML version of DAAP. It also has a much smaller original version.
http://www.tapjam.net/daap/
I used this page to decipher and process it.I used the original version simply for the fact that it’s a way smaller query response to download. The app was aimed to be used remotely, from a huge database.
The original DAAP size for my DB: 1,374,647 bytes (1.3MB)
The XML DAAP size for my DB: 3,821,141 (3.6MB)
That is quite a difference when downloading with 120kb/s.However, I still want to try RSP. But like you stated, there is no documentation to be found. I believe the author of Fireplay on this forum got some of the documentation mailed to him from Ron.
25/07/2008 at 12:24 PM #17501AnonymousInactiveI second that.. Use the DAAP interface instead of the XML-API.
The footprint of the result is much smaller, and the XML-API interface isnt as stable (i recall having a dozen problems, however for the quick query debug, its a nice feauture 😀 ).27/07/2008 at 9:58 PM #17502gurgel2ParticipantThanx guys.. ill switch to daap (possibly RSP then)
11/08/2008 at 12:43 PM #17503AnonymousInactivei’ve created a couple of classes in PHP, which should be easy to port to .NET.
Download crossfire and look for the php_dmap.php file. It contains a binairy Daap parser. If you managed to create a nice .NET class i am well up for writting a WindowsMobile .NET client.Cheers,
Tony12/08/2008 at 7:23 AM #17504EVILRipperParticipantPossibly even better; DaapPlaylistGenerator is written in C++/MFC. This program has a binary daap parser aswell. As WindowsMobile supports C++/MFC, let me know if anyone is interested in the source code. 🙂
-
AuthorPosts
- The forum ‘Add-on Software’ is closed to new topics and replies.