Sunday, December 18, 2005
Hacking "Motherload" playlists, a reverse engineering perspective
I'm on Comedy Central's Motherload all the time. I love the network's broadband channel and the range of clips that it features and the quality. I love the fact that ads run at the beginning of every second or third clip, not each and every video, prompting me to watch more. I used it as the main case study when developing my affiliate station's forthcoming streaming media player for broadband Internet access. But one thing I wish it could do better is manage playlists.
The good thing is that anyone can start using it right now if you've got a fat enough pipe, a fast enough chip and ample RAM (the Flash 8 application on which it's based is quite processor and memory intensive). But this benefit is also a drawback, because you can't easily roam with your selected clips from computer to computer, seamlessly accessing videos you've picked out from the mammoth archive as if you never left machines. I've worked around this by e-mailing myself my playlist from within Motherload, which creates the following URL: http://www.comedycentral.com/motherload/?lnk=p&ml_playlist=19385&source=OD_PLAYLIST.
Launching this in an IE browser on my office workstation (Firefox and Safari not currently supported) brings up the playlist I configured at home. It's an extra step that's admittedly not too laborious for me to do, and it works. And I didn't have to signup for anything, or create any sot of passwords. But, if I add/delete/resort more clips at work, I've got wash, rinse, repeat back to my home PC to get it to work. There isn't a centralized way for me to get at my favorite stuff.
In my own implementation, also based on Flash 8, I support playlists for my station's video archive. To retain the advantage of membership-less access, but persist their selected clips across visits, I considered a few options, dismissing them all: session variables would expire either when the browser was shut down, application variables would cause too much mucky overhead and cookies wouldn't roam. So I came up with my own following architecture of persisting playlist clips across usage sessions and machine transfers.
Basically, I use a database table that's got simple fields representing user sessions and a related table with the total available clips. When a user initially creates a playlist, an XML document is created in server-side code and then inserted into the DB. The nodeset within the XML represents the specific clips selected by the user and their ordering (a user can rearrange the sequential listing of the videos). The XML document essentially reflects any changes made to the playlist (i.e., adding, deleting, resorting) by triggering CRUD operations based on an event (OnPlaylistChanged). When a clip is moved, the event fires and the XML is updated and reposted to the database. A client-side cookie is also set linking a machine with the DB table, reflecting any changes made to the playlist in between sessions, or as my previous example highlighted, between sessions on different computers.
So this hopefully will deliver the same rich user experience as Motherload, while addressing the concern I've got about persisting playlists and playlist modifications without the burden of a membership system.
The good thing is that anyone can start using it right now if you've got a fat enough pipe, a fast enough chip and ample RAM (the Flash 8 application on which it's based is quite processor and memory intensive). But this benefit is also a drawback, because you can't easily roam with your selected clips from computer to computer, seamlessly accessing videos you've picked out from the mammoth archive as if you never left machines. I've worked around this by e-mailing myself my playlist from within Motherload, which creates the following URL: http://www.comedycentral.com/motherload/?lnk=p&ml_playlist=19385&source=OD_PLAYLIST.
Launching this in an IE browser on my office workstation (Firefox and Safari not currently supported) brings up the playlist I configured at home. It's an extra step that's admittedly not too laborious for me to do, and it works. And I didn't have to signup for anything, or create any sot of passwords. But, if I add/delete/resort more clips at work, I've got wash, rinse, repeat back to my home PC to get it to work. There isn't a centralized way for me to get at my favorite stuff.
In my own implementation, also based on Flash 8, I support playlists for my station's video archive. To retain the advantage of membership-less access, but persist their selected clips across visits, I considered a few options, dismissing them all: session variables would expire either when the browser was shut down, application variables would cause too much mucky overhead and cookies wouldn't roam. So I came up with my own following architecture of persisting playlist clips across usage sessions and machine transfers.
Basically, I use a database table that's got simple fields representing user sessions and a related table with the total available clips. When a user initially creates a playlist, an XML document is created in server-side code and then inserted into the DB. The nodeset within the XML represents the specific clips selected by the user and their ordering (a user can rearrange the sequential listing of the videos). The XML document essentially reflects any changes made to the playlist (i.e., adding, deleting, resorting) by triggering CRUD operations based on an event (OnPlaylistChanged). When a clip is moved, the event fires and the XML is updated and reposted to the database. A client-side cookie is also set linking a machine with the DB table, reflecting any changes made to the playlist in between sessions, or as my previous example highlighted, between sessions on different computers.
So this hopefully will deliver the same rich user experience as Motherload, while addressing the concern I've got about persisting playlists and playlist modifications without the burden of a membership system.
Comments:
Links to this post:
<< Home
Hi Jason,
Is this something you've gotten to work or something you are thinking out loud with? It's an interesting problem though I'm still not sure how the solution you've described solves the problem of "knowing" who you are in the event you'll be accessing your site from some random computer. You mention the use of cookies linking a machine to a DB table but isn't this falling in to the same "cookies wouldn't roam" pitfall? Just to be sure I'm not mis-understanding the problem - here's a description of a simple usage scenario I think you are trying to achieve - without the use of any sort of account information.
1. user accesses your site from computer A and creates a playlist.
2. user accesses your site from computer B sees previously created playlist
3. user updates playlist from computer B
4. user accesses site from computer A and sees updated playlist
Is this correct? As far as I can tell - you won't be able to do this without the use of some sort of account information mapping users to playlists or ip checking (hack) that would be ill advised in this context.
Is this something you've gotten to work or something you are thinking out loud with? It's an interesting problem though I'm still not sure how the solution you've described solves the problem of "knowing" who you are in the event you'll be accessing your site from some random computer. You mention the use of cookies linking a machine to a DB table but isn't this falling in to the same "cookies wouldn't roam" pitfall? Just to be sure I'm not mis-understanding the problem - here's a description of a simple usage scenario I think you are trying to achieve - without the use of any sort of account information.
1. user accesses your site from computer A and creates a playlist.
2. user accesses your site from computer B sees previously created playlist
3. user updates playlist from computer B
4. user accesses site from computer A and sees updated playlist
Is this correct? As far as I can tell - you won't be able to do this without the use of some sort of account information mapping users to playlists or ip checking (hack) that would be ill advised in this context.
# posted by 
: December 18, 2005 12:05 PM
: December 18, 2005 12:05 PM
Hi Jonah,
It's moving from the conceptualization to the coding phase at the moment. Oops...I guess I didn't mention well enough that the cookie, if existing, links to the unique ID of the DB table and pulls the selected clips from that profile. But this assumes the cookie's already there.
But you're totally right...the cookie solution doesn't completely take care of the roaming. I try and avoid membership as much as possible for simple things like this. I've thought about IPs or other tracking mechanisms, or dynamically updating cookie values if other computer modify the playlist.
It's moving from the conceptualization to the coding phase at the moment. Oops...I guess I didn't mention well enough that the cookie, if existing, links to the unique ID of the DB table and pulls the selected clips from that profile. But this assumes the cookie's already there.
But you're totally right...the cookie solution doesn't completely take care of the roaming. I try and avoid membership as much as possible for simple things like this. I've thought about IPs or other tracking mechanisms, or dynamically updating cookie values if other computer modify the playlist.
Hi Jason,
I agree that avoiding membership for simple things like this is probably much appreciated by your users. I do however believe that even the less sophisticated user wouldn't expect for any system to just magically know who they are without providing any information and regardless of where they are coming from. And if it did - it's probably some kind of creepy voodoo tracking system that we should all be concerned with..
Anyway, I think what you are doing is about all that can be done given the no membership requirement .. identifying returning users based on cookie information and delivering their customized content.
I agree that avoiding membership for simple things like this is probably much appreciated by your users. I do however believe that even the less sophisticated user wouldn't expect for any system to just magically know who they are without providing any information and regardless of where they are coming from. And if it did - it's probably some kind of creepy voodoo tracking system that we should all be concerned with..
Anyway, I think what you are doing is about all that can be done given the no membership requirement .. identifying returning users based on cookie information and delivering their customized content.
# posted by : December 19, 2005 9:11 PM
: December 19, 2005 9:11 PM
Yeah...but I'm a programmer who sets his mind on one specific feature and will walk through fire until I figure out how to do it.
So until the day I can figure out proper roaming sans membership, I won't be sleeping well at night. :-)
So until the day I can figure out proper roaming sans membership, I won't be sleeping well at night. :-)
Hi Jason,
I understand completely - I can definitely relate. Sometimes you have to go through the motions yourself and draw your own conclusions no matter what anyone says. Having said that - I'm still struggling with the concept - independent of technology and the details. The concept of being able to identify a previous guest of yours with nothing more than a knock at your door. As a programmer myself - I'd need to find some solution to this, at least in theory before I take the next step. It's so much less costly to find / fix issues in design (in this case conceptual design) than it is in implementation.
Please keep us posted on what you finally come up with. It will definitely be something many will be interested in.
Thanks!
I understand completely - I can definitely relate. Sometimes you have to go through the motions yourself and draw your own conclusions no matter what anyone says. Having said that - I'm still struggling with the concept - independent of technology and the details. The concept of being able to identify a previous guest of yours with nothing more than a knock at your door. As a programmer myself - I'd need to find some solution to this, at least in theory before I take the next step. It's so much less costly to find / fix issues in design (in this case conceptual design) than it is in implementation.
Please keep us posted on what you finally come up with. It will definitely be something many will be interested in.
Thanks!
# posted by : December 21, 2005 9:31 AM
: December 21, 2005 9:31 AM
You bet! I'll keep you posted and thanks for the suggestions/help with your comments...I appreciate it.
Just for reference, here's the format for the membership-less VSpot broadband channel that VH1:
http://www.vh1.com/vspot/?lnk=v&vid=40745&source=VS_VIDEO:undefined:Behind+These+Hazel+Eyes+%28Live+%40+VH1.com%29#40745
Post a Comment
Just for reference, here's the format for the membership-less VSpot broadband channel that VH1:
http://www.vh1.com/vspot/?lnk=v&vid=40745&source=VS_VIDEO:undefined:Behind+These+Hazel+Eyes+%28Live+%40+VH1.com%29#40745
Links to this post:
<< Home
Subscribe to Posts [Atom]
