Auto-Discovery & Streaming through port 1400 (1 Viewer)

ssimon

New Member
April 26, 2006
4
0
I am a longtime user of the XBMC and I love how you can use the "Auto-Discover" feature of XBMC to connect to a remote media server (running a service like ccxgui) through port 1400

Is there such a feature/plugin for MediaPortal?

I already have computer setup as a media server and it is already running the server software which broadcasts/listens to requests on port 1400 so I'd like to take advantage of it...

Thank you.
 

ssimon

New Member
April 26, 2006
4
0
Bummer. having automatic detection of machines sharing media files (even on DHCP) is in my mind one of the most powerfull features you can have.

I use CCXGUI running as a service in XP (no need to even log into the machine) to serve media to an XBOX running XBMC and it works flawlesly. ccxgui can be found HERE for free download and Screenshots are HERE

I would really like to see a plugin or new functionality to allow MediaPortal to take advantage of this!!!
 

ssimon

New Member
April 26, 2006
4
0
As MediaPortal started as a port of XBMC and is now 2 years old, it is really confusing to see no ccxgui dynamic server support...
 

BoelShit

Portal Pro
November 6, 2005
235
8
44
Home Country
Netherlands Netherlands
Isnt that ccxgui just a program to create some shares? So in other words I can set up shares on my pc's and enter them manually in MP will do the same.

I think there is no need for MP to auto-discover shares on the network. If a share is needed they will be created by the user and MP is directed to that one by configuration.

It's only my opinion... but maybe for some more ppl around here.
 

ssimon

New Member
April 26, 2006
4
0
BoelShit said:
Isnt that ccxgui just a program to create some shares? So in other words I can set up shares on my pc's and enter them manually in MP will do the same.

I think there is no need for MP to auto-discover shares on the network. If a share is needed they will be created by the user and MP is directed to that one by configuration.

It's only my opinion... but maybe for some more ppl around here.

CCXGUI does more than create shares, it "broadcasts" them via port 1400 TCP. On the Xbox I do not care about IP's, share names, server name or IP (pc running ccxgui), etc... it is all transparent and automated. Even if someone brings their Xbox to my house there is no need for them to configure anything, it just auto-detects everything and works Automatically!

Shares should be created/maintained in ONE place, the server/machine hosting them, you should not have to do anything special on any of the one or more client systems accessing them!

My argument is as follows: If dual manual configuration was so easy, why was DHCP invented? Same applies here!

CCXGUI acts like a DHCP server and the XBMC (and hopefully Media Portal will soon) acts like a DHCP client!
 

gxtracker

Retired Team Member
  • Premium Supporter
  • July 25, 2005
    316
    2
    Home Country
    Canada Canada
    DHCP was invented for administering hundreds or thousands of IP addresses. Now If you had hundreds or thousands of MP boxes, I would agree with you. :D

    but considering most people have 1 or 2 - maybe - 4 or 5 thin client MP boxes maximum, I simply dont see the need for autodiscovery the way I think you're describing it.

    One thing that is being planned is database sharing between MP installations, so that you can browse your media library on one box and if a specific media file is on another machine, MP will automatically stream the content from that MP box. This will allow for a decentralized database which will update as new media is added to it. This concept will most likely find its way into future releases - past 0.2.0.0 final.

    It's a different method than ccXstream, but in the end the results should be simpler on the development team, as well as easy enough for the average user.

    Of course, if someone wants to develop a plugin and do it themselves, no one will stop them. ;)
     

    Users who are viewing this thread

    Top Bottom