RE: How to Distribute xPLMediaNet

["Tony Tofts" <tony@xxxxxxxxxx>]

Hi Andy,

> I do still have an issue with re-scanning... Is it also
> possible to add
>
> a) a small cli app to scan, so I can at least see what's
> being added (if anything)

I'll look at adding something, maybe just a web page that pop's up at the
end with a list of everything added and any errors? The current web page,
if
refreshed, shows what's being scanned but isn't reatime due to the need to
refresh. If anyone can tell me how I can push info at a web browser I may
be
able to do something neater...

> b) a method to only scan a specific folder, I don;t need to
> rescan everything if I've only added 1 cd.

Not sure how to accomplish that. Would need some sort of browse function in
the web page? Will keep this in mind but doubt it will be in the first
release unless someone can come up with some code for me to use.

> c) some error messaging with scan failures. ATM it's sitting
> there telling me it's "Paused" but I doubt it's true

See 'A'

> Ok, personally I'm inclined to want to download a complete
> app with all the plugins at once, I don;t like having to
> download 20 different ones, and then install each...
> I get enough of that with linux ;)

Fair point. My current thinking is that the core install will include all
the standard music sources (i.e. excludes things like tivo and
pictures/videos) and support modules.

So a "Rio only" user would install the core, and then dowload and
uzip the
rio install (which would include all the rio support modules)

So 2 downloads for a rio user. Though if they want 'extras' like a dhcp
server this would still be separate (though I may decide to include this in
the core but disabled).

When installing the MVP (and similar devices) zip it would include the
video
and picture sources (though tivo would remain separate, as it's not
required
by most users)

> But there is no reason that the config files shouldn't be split.

Managed to find a few hours over the weekend to make some progress on this.
Have now split everything up, though I'm going to revisit it again to
change
it so that rather than loading multiple instances of a dll from a single
loader.xml, it looks for multiple xml files instead. The reason for this is
that if a support module (e.g. tftpd, nfs) is shared between 2 or more
devices then we don't want a rio install, for instance, to overwrite an
existing working yyy device config for that same dll. So instead of
loader.xml, we might have loader_rio.xml and loader_yyy.xml. So the core
will look for loader_*.xml files.

This sounds quite messy/complicated, but it's consistent so shouldn't
present any problems. The loader code in the new version is about a 1/4 the
size of the original, so everythings much neater now. And the layout of the
xml files is consistent for all modules regardless of whether they are
device/support/source etc modules

> I'd prefer to be able to enable/disable things without having
> to delete the folder.

Each loader instance has it's own enabled="y/n", so no need to
delete a
folder to disable

On a separate note the dependency on xPL is to be removed before the next
release. xPL will become an independent interface module therefore allowing
users to integrate xplmedianet into there own system if required, or change
the xpl functionality to suit themselves. This is quite a big change as the
web interface currently depends totally on xPL. The xPL module will also,
at
some point, support scripting.

Regards
Tony



xPL Links: http://www.xplproject.org.uk http://www.xplhal.com http://www.xpl.myby.co.uk
To Post a Message: ukha_xpl@xxxxxxx
To Subscribe:  ukha_xpl-subscribe@xxxxxxx
To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx