Announcement

Collapse
No announcement yet.

Proposed Web Service: Online Playlist Management

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Proposed Web Service: Online Playlist Management

    This service would allow users to sync their playlists between the carPC and the web service. Playlists could also be created online and then automatically synced with the client.

    Client Definition:
    • sendPlaylist(string sessionKey, string playlistName, string playlist)
      Playlists should be in SMIL format
    • sendPlaylist(string sessionKey, string playlistName, string[] url)
      URLs should be relative paths
    • string getPlaylist(string sessionKey, string playlistName)
      Response should be in SMIL format
    • string[] getPlaylistURLs(string sessionKey, string playlistName)
    • string[] getNewPlaylists(string sessionKey, DateTime start)
      Returns an array of playlist names which must then be retrieved
    openMobile - An open source C# Front End (why choose openMobile?)
    - Always Recruiting Developers -
    Like what you see? Donations are always welcome

  • #2
    Creation of playlists online would be very hard to do. First, we would need to know the songs on both the desktop/client at all times. The amount of BW required for this would be immense and very costly.

    Using the proximity service, we could instead just sync folders. The user could then create the playlists locally on the system and then when the sync happens, the playlists get downloaded to the client.

    What are your ideas on this?

    Comment


    • #3
      Sending up a list of songs shouldn't be too expensive in BW. But I guess that depends on the data we send up. Are we sending up title, artist, and album? or just title? my guess is that at most 10,000 is still going to be less than 1 MiB of data.
      Former author of LinuxICE, nghost, nobdy.
      Current author of Automotive Message Broker (AMB).
      Works on Tizen IVI. Does not represent anyone or anything but himself.

      Comment


      • #4
        For all data services i'm figuring on an average 3G connection or ~50KB/s but in many places its more like ~10KB/s, which can make each MB significant.

        Online playlist was probably the wrong choice of words...I was thinking more along the lines of uploading playlists and having them sync that way. If we use relative paths with everything it should work pretty well.
        openMobile - An open source C# Front End (why choose openMobile?)
        - Always Recruiting Developers -
        Like what you see? Donations are always welcome

        Comment


        • #6
          You aren't talking about the services that match your "album" to likely matches (for those like me that put backups on their PC)? Not that I've tried it on an individual song basis - but that wouldn't be how they are set up.

          (No - I didn't think so. It was too obvious.)

          Comment


          • #7
            What do you plan on doing with these playlists once they are in the webservice? Without songs and song data to accompany them, they are pretty useless. And as you realized, uploading info about every song is costly in bandwidth and time.

            Comment


            • #8
              We could use the title and artists fields of the smil playlist format and a web based metadata service to allow adding and remove songs to/from playlists which would then be matched to a users local files when synced.

              But actually I was just talking about a sync service for playlists. We already have one for music and such (which I think the goal was to do locally if possible). I know a few users like setting up playlists on their home PC's since their easier to manage and then transferring them to the car. This service would do it automatically and translate the relative paths.
              openMobile - An open source C# Front End (why choose openMobile?)
              - Always Recruiting Developers -
              Like what you see? Donations are always welcome

              Comment


              • #9
                Originally posted by Nextabyte_Matt View Post
                What do you plan on doing with these playlists once they are in the webservice? Without songs and song data to accompany them, they are pretty useless. And as you realized, uploading info about every song is costly in bandwidth and time.
                Actually doesn't this sound like the way to go? If you make the assumption that you are using this web service for YOUR vehicle, then you have your songs locally, then upload your playlist data to the cloud. Now you can work with your playlist at home, at work, wherever, and as long as those songs exist at the location when you try to use that playlist it can play them. Even if you are in someone else's car you signin and use your playlist, and it is smart enough to play what it can, and skip what isn't there.

                Storing MP3's online seems to be the wrong direction?

                Comment


                • #10
                  No one was talking about storing mp3s online...that was just a miscommunication. What your talking about is far more complicated then it seems due to the possibility of duplicate songs or name scheme differences. It would also not be useful to "edit" a playlist without the songs that its referencing hence my edit before upload approach.
                  openMobile - An open source C# Front End (why choose openMobile?)
                  - Always Recruiting Developers -
                  Like what you see? Donations are always welcome

                  Comment


                  • #11
                    So this would just be a basic sync service around a SMIL file? And you are not envisioning the case where the user would create the playlist online (which would require the server to know about the media contents of the carpc)? The story that this service covers is you create a playlist locally via whatever software you have to create playlists, and just sync it to the carpc?

                    If I'm correct in my understanding, this could work. I'd personally like to see server awareness of the media contents happen so I can edit/create playlists from wherever. But yeah, that requires the server to know the title (possibly artist, album, genre, etc) and the path of every song which is constly in BW.

                    However, we could handle transferring of data in a BW efficient sort of way. For example, sending up a bzipped/gzipped/7zipped bytearray instead of a stringlist... Just thinking out loud.
                    Former author of LinuxICE, nghost, nobdy.
                    Current author of Automotive Message Broker (AMB).
                    Works on Tizen IVI. Does not represent anyone or anything but himself.

                    Comment


                    • #12
                      well yea and no.... assuming 100,000 songs, 100 characters per relative path, 400chars for album, artist and title...thats 48MB...using 7zip compression thats probably around 24MB which is doable. While yes that may seem like more then the average user the bigger issue is going to be storage. There aren't too many easy ways to store millions of records server-side in a way thats fast to work with.
                      openMobile - An open source C# Front End (why choose openMobile?)
                      - Always Recruiting Developers -
                      Like what you see? Donations are always welcome

                      Comment

                      Working...
                      X