FireFly Media Server › Firefly Media Server Forums › Firefly Media Server › Add-on Software › FirePlay Flash client for FireFly
- This topic has 873 replies, 99 voices, and was last updated 14 years, 6 months ago by beaon.
-
AuthorPosts
-
09/04/2008 at 6:08 AM #13971Bo MellbergParticipant
The issue you are referring to is all about the ordered list. I’m still waiting for FireFly to support ordered, limited sql queries, which will enable me to populate the song list correctly without having to wait for the complete playlist to download.
It’s really a design road I’ve chosen, to minimize the waiting. The behaviour is the same with the library, it does not populate the song list until you have chosen an artist.
You can “override” by selecting all artists. Be prepared for long download waiting though.
The playlist generation is a really dirty hack. Cut’n’paste the XSPF-text into a new text document and name the document “playlist.xspf”. Any xspf-capable application (like foobar2k) will be able to stream the playlist from your server.
09/04/2008 at 12:26 PM #13972AnonymousInactiveGreat — thanks for the speedy response/explanations. I just wanted to make sure it was behaving as expected and I wasn’t doing something wrong.
I’ll take a look at the XSPF stuff tonight now that I know how to use it. Sounds interesting.
mj
09/04/2008 at 1:49 PM #13973AnonymousInactiveThe download restriction works great Bo, but how can I protect the daapd server. As my setup is now, fireplay.html is protected on a web server and a user has to enter their LDAP username and password to get access. But if someone set up fireplay on their own web server, they can direct it to the ip and port my daapd (firefly) server is running on, and download any song they want. I don´t think it´s possible to add LDAP authentication to firefly so the only solution that I see is to add a password to firefly and make fireplay connect with that password automatically. Is that possible or is there an easier solution?
09/04/2008 at 2:01 PM #13974Bo MellbergParticipantI haven’t implemented any password protection at all, I’m relying on the admin password, to be able to reach the admin-root directory at all, OR placing the three files in a password protected directory.
What about telling FireFly to only connect locally? If you have FirePlay on the same physical server that could work.
My own firefly-setup (/etc/mt-daapd.conf) includes:
interface = eth1
Which makes only local connections possible, ie from local network (Soundbridge) or FireFly (which is also “local”) even though the client is remote via port 3689.
EDIT: Oops. I just read the wiki and “interface” seems not to be supported. Forget the above 🙂
10/04/2008 at 9:51 AM #13975Bo MellbergParticipantI finally added a readme to the package. Hopefully this will help with some of the initial setup issues we have seen.
/Bo
20/04/2008 at 3:41 PM #13976AnonymousInactiveI had the same problem frequently reported here, and couldn’t figure out it was – I was running latest mt-daapd, and had rsp enabled, but fireplay kept hanging on ‘Connecting…’
A trace showed it was trying to load crossdomain.xml, which didn’t exist. Without that, flash doesn’t appear to allow data to be read from a site. Creating it solved my problem, but added another one…
I have fireplay on my primary server, and it doesn’t require authentication, but it’s trying to load crossdomain.xml from :3689, and gets an authentication request. I know in iTunes, I don’t need to authenticate, and would gather it’s specifically because crossdomain.xml resides in the admin-root.
Is it possible to change this so it doesn’t ask for authentication? Is it possible to get rid of the need for this file, or get it included into mt-daapd automatically? Did I miss something, since I don’t see references to it in the readme?
Thanks!
20/04/2008 at 9:51 PM #13977Bo MellbergParticipantGreat work jennytoo! You have pinpointed a problem that a lot of people have struggled with for long.
crossdomain.xml is a file that resides on a server for the purpose of telling other calling flash objects that they are allowed to retrieve data from that server.
The thing is, you are retrieving xml-information from port 3689 (rsp replies), which makes the flash code try to find crossdomain.xml on that server. If it doesn’t find it, you wont be able to serve your primary server with xml from that 3689-server.
You added a “crossdomains.xml” into the admin-root. I guess it looks like this:
The asterisk meaning that this server will comply requests from all requesting flash objects, whatever domain the call comes from. This should help a lot of people. Create this file, stick it in your admin-root and your good to go.
BUT, to be able to read that crossdomain.xml file you need to authenticate yourself to that server, using your admin password. I’m afraid I can’t do anything about that. Every file served out from the admin-root directory, has to be authenticated. Unless I can add the user/pass in the http-request.
EDIT: I tried connecting to “http://admin:[email protected]:3689 and it actually worked, apart from a dialog coming up saying I was about to connect using the username “admin” etc etc.
So perhaps if I make all requests in this way, the loading of crossdomain.xml wont have to be authenticated.
The absolute best thing would be if firefly could serve the crossdomain.xml whenever it was asked for. You could ask Ron to implement this.
21/04/2008 at 7:35 AM #13978Bo MellbergParticipantI have made some more tests, resulting in the following:
1. All files in admin-root. No crossdomain.xml needed.
2. All files located on separate Apache server. FirePlay.html edited with the FireFly server address and port. No crossdomain.xml needed.It’s still the same physical server though, so these test are quite useless for you, jennytoo.
If you can, try running FirePlay in old Flash Player version 6. It is not equipped with the crossdomain security checks:
22/04/2008 at 1:24 AM #13979AnonymousInactive@Bo Mellberg wrote:
I have made some more tests, resulting in the following:
1. All files in admin-root. No crossdomain.xml needed.
2. All files located on separate Apache server. FirePlay.html edited with the FireFly server address and port. No crossdomain.xml needed.It’s still the same physical server though, so these test are quite useless for you, jennytoo.
If you can, try running FirePlay in old Flash Player version 6. It is not equipped with the crossdomain security checks:
1 – fireplay itself in admin-root? Would need to be authenticated to get to fireplay, but then wouldn’t need it as same site, if I follow right?
2 -In my setup, both the apache server and the firefly server are on the same machine, just different ports. The fireplay files live on the apache server, and fireplay.html has the entries for firefly server/port. This is my setup, and it /does/ want crossdomain.xml, unless I did something wrong?
…
unless… I’ll have to check something out. I’ll bet what’s going on for me is the interaction between the apache webserver (which reports itself as the externally visible hostname, which is a different address) and the firefly server (which uses the internal address, on the same machine) … it’s seeing a mismatch on the IPs. Will have to play with that.
I’m playing with this specifically for use on my Wii which I just got. Seems like it’d make sense to use it as a mediaplayer, although so far if I let it play, after about half an hour it complains of memory exhaustion.
22/04/2008 at 5:51 AM #13980Bo MellbergParticipant@jennytoo wrote:
1 – fireplay itself in admin-root? Would need to be authenticated to get to fireplay, but then wouldn’t need it as same site, if I follow right?
Yes, this is the preferred setup, as described in the readme.
@jennytoo wrote:
unless… I’ll have to check something out. I’ll bet what’s going on for me is the interaction between the apache webserver (which reports itself as the externally visible hostname, which is a different address) and the firefly server (which uses the internal address, on the same machine) … it’s seeing a mismatch on the IPs. Will have to play with that.
I guess thats it. If the swf-file and FireFly can be reached by the same ip/hostname, crossdomain.xml wouldn’t be needed.
@jennytoo wrote:
I’m playing with this specifically for use on my Wii which I just got. Seems like it’d make sense to use it as a mediaplayer, although so far if I let it play, after about half an hour it complains of memory exhaustion.
I think this was mentioned in early in this thread, but I’m not sure.
-
AuthorPosts
- The forum ‘Add-on Software’ is closed to new topics and replies.