foo_httpcontrol, control foobar via http Options

[oblikoamorale]

This foobar2000 1.0+ component is developed as replacement for Media Player Classic web control interface, which I used quite a lot, but still didn't like it, as it missed quite a number of features I'd like to have. Also I felt it's a shame such great player as foobar2000 couldn't be remotely controlled over http nowadays. So, erm, I went ahead and somehow developed component featuring functions I use by myself on everyday basis.

This component provides the following features via http interface:
- full control of playback, including seekbar;
- basic playlist support;
- basic playback queue support;
- basic media library support;
- basic file browser functions, including ability to browse Microsoft Network;
- a few UI custimization abilities.

Stock interface template is written using synchronious document model (with basic CSS and JS), and has been tested and proved itself working on any modern browser: Opera, Firefox, Chrome, Safari. Stock interface screenshot

Download foo_httpcontrol
Changelog

User submitted templates for component version 0.96.5 and newer:
for desktop PC browser:
ajquery (jQuery UI based)
default (brain dead simple)
by vakata fix
Opera sidebar, by Ritsl
by vairulez

for mobile devices:
SimpleBasic, for iphone/ipod touch, by L4nt0m
iPhone, by lxofith (vast improvement of Joror template) fix
G1 Android (also Chrome/Safari/Firefox/Opera/iPhone compatible), by Kev0 fix
experimental autoscaling, by Kev0 (based on lxofith work)
foodroid2000, native Android client, by bugramovic
for Android, by regi24
for 320x240 screens, by kaFFee666
for Nokia N900, based on vakata2, by yolan
iPhone and iPad remotes, by vogliadicane

Illustrated beginner's guide to the component.

This post has been edited by oblikoamorale: Nov 23 2011, 16:20

[Tim Schuhmacher]

...
Also it would be nice if there was a way to see enqueued tracks...

That can be achieved by requesting the content of the queue playlist, so that funcionality is already present.

Oblikoamorale, your new idea of implementing queue and cursor management controls, does that mean extra refreshing of the webpage?

And would it be possible to come up with variations of [PLAYLIST]. So maybe [PLAYLIST_WITH_DELETE] and [PLAYLIST_WITH_ENQUEUE] etc? So that I has a user can 'create' my best configuration for the webpage? Or some options in the properties in foobar with checkboxes that represent the items to be included in the webpage? The last option is maybe more user friendly.

[oblikoamorale]

...
Also it would be nice if there was a way to see enqueued tracks...

That can be achieved by requesting the content of the queue playlist, so that funcionality is already present.

not quite right, queue information has to be requested separately. I'm still considering the best way of showing queue within the existing playlist without introducing any other (table) data. color highlighting might be a good compromise even although it introduces some problems, for example, when one track is queued several times.

Oblikoamorale, your new idea of implementing queue and cursor management controls, does that mean extra refreshing of the webpage?

one refresh per one action, that is the way it is designed.

And would it be possible to come up with variations of [PLAYLIST]. So maybe [PLAYLIST_WITH_DELETE] and [PLAYLIST_WITH_ENQUEUE] etc? So that I has a user can 'create' my best configuration for the webpage? Or some options in the properties in foobar with checkboxes that represent the items to be included in the webpage? The last option is maybe more user friendly.

the ultimate way to satisfy any end user wishes would be to transfer all web page playlist formatting to user end. what I mean is that template's javascript receives some sort of playlist data array, and generates the playlist section of the page by itself. I didn't benchmark this approach yet, but my guess it's going to be quite expensive, considering this stuff is being used on some mobile devices.

[Hamallainen]

Nice, it all seems to work fine here. Thanks for the improvements
IMO it would be better if the dropdown action list could remember the last action.

not quite right, queue information has to be requested separately. I'm still considering the best way of showing queue within the existing playlist without introducing any other (table) data. color highlighting might be a good compromise even although it introduces some problems, for example, when one track is queued several times.

Color highlighting is ok for me. I don't know if it's possible but maybe a tooltip showing the queue position(s) would be enough, at least for me.

That can be achieved by requesting the content of the queue playlist, so that functionality is already present.

I had not thought about it. Thanks for the tip.

[oblikoamorale]

Color highlighting is ok for me. I don't know if it's possible but maybe a tooltip showing the queue position(s) would be enough, at least for me.

I'm not exactly sure what do you mean, a way of indicating the playback progress within the queue?

That can be achieved by requesting the content of the queue playlist, so that functionality is already present.

I had not thought about it. Thanks for the tip.

ah, right. he meant foosion's playback queue plugin, didn't he?

to everyone: can you post screen shots or screen photos of plugin running on your pda or mobile phone or whatever exotic or not so exotic devices? or perhaps some of you modified the front end appearance or behaviour in one or another way, what is also quite interesting for me. I absolutely wouldn't mind seeing or reading the feedback. thanks

[Hamallainen]

Color highlighting is ok for me. I don't know if it's possible but maybe a tooltip showing the queue position(s) would be enough, at least for me.

I'm not exactly sure what do you mean, a way of indicating the playback progress within the queue?

Well not the playback progress in minutes/seconds, i was just talking about eventually showing the enqueued tracks position(s)/index(es) within the playback queue. But with Tim Schuhmacher's suggestion it's maybe not needed except it requires to install an extra component. In fact I was suggesting this because you said :

I'm still considering the best way of showing queue within the existing playlist without introducing any other (table) data. color highlighting might be a good compromise even although it introduces some problems, for example, when one track is queued several times.

[oblikoamorale]

Well not the playback progress in minutes/seconds, i was just talking about eventually showing the enqueued tracks position(s)/index(es) within the playback queue.

I've thought of adding an additional playlist column with serial number of enqueued track within playback queue, but considered it as a minor thing. if you think it'll improve usability, I'll add it, no problem.
It's just me who didn't (and still doesn't) use queueing at all.

There are two things that I am looking for:
a) instead of a complete webpage returned I only need a string with the track info/file name etc.
b) Volume Up and Volume Down instead of setting the volume to a certain percentage (I might have the control interface on screen on more than one machine.

first request is possible by changing the page template. take a look at its inside, it isn't complicated. volume control in this way is not possible at the moment, but again, there's no big deal to implement it (if it is needed).

I will try to make a picture of your component in action on my SonyEricsson w950i phone.

thanks, much appreciated.

I do experience one problem. Maybe this problem did also exists in the previous version. I have a playlist with online radio streams. When listening to a stream the progress bar shows some strange behaviour.
[...]

well, it is no surprise radiostreams cause some problems considering the fact they don't have any fixed length. I'll fix it (or try to, at least).

This post has been edited by oblikoamorale: May 12 2008, 16:06