-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XSPF Playlist import/export #8629
Comments
Commented by: daschuer The final goal looks somehow similar to this: I would like to focus this bug on Playlist export. A next step could be to save the cue-in and cue-out points and the fade time. |
Commented by: antonio2016 Yes, somehow XSPF must be extended in several directions. Afterall is X SPF. |
Commented by: daschuer We could add these infos to the History playlist. An other issue is that the History playlist has no dedicated start and end event. It starts and ends with Mixxx, which is not equal to the start and end events of your radio show. So how about using the standard XSPF file as a inter-operable format for all players and "record" all control events in a second stream based file. This could also be a binary blob inside the XSPF file. |
Commented by: antonio2016 Must be surely something like this. Simply have no idea what is the simplest to implement in Mixx. |
Commented by: daschuer Compiling Mixxx on W10 is a pain. We have only a few contributors who have managed it. |
Commented by: illuusio I investigated this little bit. In general form XSPF/JSPF doesn't do what we want. Although it has extension system what VLC uses to extended XPSF (https://wiki.videolan.org/XSPF/) which gives at least second start and stop but again it's not as accurate as we need. One option is adopt: XML that are compatible with: MLT framework (https://www.mltframework.org/bin/view/MLT/MltXml) so one can tune mixes and then render it offline. For people who just requires played songs we should use CSV file. Easiest to parse and use with Word or Libreoffice. Just couple ideas to get this done. |
Commented by: macrophone I would like to easily import xspf playlist generated by clementine without absolute path. Other types of playlist format rely on absolute path so if the file is not at the right place it doesn't show up in the imported playlist. |
Commented by: macrophone sorry my previous comment is not correct: my problem is that relative path are not imported, witch is related to : |
Reported by: antonio2016
Date: 2016-08-26T21:44:30Z
Status: Confirmed
Importance: Wishlist
Launchpad Issue: lp1617466
Tags: cue, hackathon, playlist
Hi folks. I am trying to attract attention to this idea below. Basically I' d like to set up a radio with, possibly, very few listeners.
Tried with Radionomy and was cancelled several times not to meet their minimum audience. Radionomy was unsatisfactory, also, for the limitation on their database.
Many songs I'd love were not there. So I would like to develop a consistent approach for this and I am not finding the appropriate resources. May be it is time to write something myself? Ideally Mixx should be used to produce a Radio program. Once one is satisfied with his program basically has a list of URL for the songs he has found on the net plus a number of vocal Dj intervention Mixx is keeping in his memory. This can be described as a .cue file.
If one is satisfied with streaming a sequence of song-comment-song etc. then it is quite straightforward to put your vocal intervention mp3 on some server, build a XSPF playlist, put a XSPF player on a web page and have a radio.
The listener runs the XSPF player embedded in the web page of the radio and downloads each song and each dj comment.
In a more advanced scenario XSPF capabilites are extended and the client is modified to mix two tracks so that we can have a DJ doing his intervention while music is playing. This is quite straightforward since, right now, there are XSPF players that crossfade two subsequent mp3.
Finally some middleware is needed. You can stream this way a program but a radio needs something more. Therefore you need a good bunch of PHP code dealing with
assembling XSPF playlist, one for each single program, into a XSPF for the whole day, upload it to your server. Handle monthly plannig and so on.
Finally we can imagine some plus.
First the communication with clients could be secured and therefore XSPF is passed to the client in encoded form.
Next either the PHP server and the client could receive several URL for the same song and try to adapt is some link went dead.
When this happens the PHP server could inform radio programmer that a certain shortage of options, for a certain song, comes up.
The text was updated successfully, but these errors were encountered: