1.05-wdtvext-beta
Contents
Intro
Here is a short summary compiled by recliq about the information regarding the beta 1.05 live firmware with experimental wdtvext support that is available in the Area 51 forum subcategory. It is meant to help those without access build and run the beta firmware. For up to date information refer to the forum thread: http://forum.wdlxtv.com/viewtopic.php?f=51&t=6848 Mad ady 07:16, 27 January 2014 (UTC)
Download
Hi,
as requested I packed an actual SVN checkout of 1.05.04-WDLXTV-Live and included pibos new WDTVExt for 1.05. This is root.bin updatable from SVN but will mark several files as modified.
If this version shows to work fine I'd like to make this the main test version for WDTVExt, so we just need to exchange libext.so. @pibos: Possible? Any problem with this?
The root.bin is tagged as 105_svn.
* 1.05.04-Ext3-Boot-Live-svn incl. WDTVExt (multiupload.nl) * 1.05.04-Ext3-Boot-Live-svn incl. WDTVExt (mediafire.com)
If you can't download from uploaded.to this link, PM me and I can provide a direkt link to my server.
Work already done:
- (re-)included WDTVExt
- (re-)included internal WDTVExt plugins (Reloader, MediaMark, ExtSheet), the rest is included as well but not tested/patched yet.
- patched XML files for ExtSheet and MediaMark plugins
- included additional images for Reloader and MediaMark plugins
To Do:
- patch WEC to display WDTVExt tabs again see Fix 2
- test other plugins
Greetz, recliq
FIXES/PATCHES
Here I will post some bugfixes you may need to apply to get every plugin working as before...
FIX 1: You may need to add the script oneDelaySelectionFix from 1.02 SVN for some plugins to work properly.
- Download an install devtools.app.bin
- Add oneDelaySelectionFix from 1.02 firmware:
cd /usr/bin svn export https://svn.wdlxtv.com/svn/wdlxtv-live/trunk/usr/bin/oneDelaySelectionFix
FIX 2: Fix WDTVExt tabs in WEC. Download and extract the fixed files from here: fix_WDTVExt_WEC.tgz and extract the contents in /.
cd / wget http://files.wdlxtv.de/fix_WDTVExt_WEC.tgz tar xvzf fix_WDTVExt_WEC.tgz
SVN Update
To get the most recent svn patches (such as UMSP_LAN) you can run these commands after you've booted the firmware:
cd /boot svn update
Troubleshooting wdtvext plugins
I switched to this FW and it looks good, but the plugin I wrote is no longer found. wdtvext.log
Collecting WDTVExt plugins... searching in /tmp/wdtvext-enabled-plugins System plugins found: /wdtvext/plugins/P00Reloader/Reloader.plugin.js /wdtvext/plugins/P10ExtSheet/ExtSheet.plugin.js User plugins found: done. Collected 2 plugins... took 675ms
From the base of the stick you can see I have tried two locations:
# find . -name ShoutcastNowPlaying.plugin.js ./ShoutcastNowPlaying.plugin.js ./.wdtvext-plugins/ShoutcastNowPlaying.plugin.js
Do I need to add the meta data?
recliq wrote:@Herbie: If you already have a file /conf/wdtvext-plugins, delete it and reboot (it will be re-created with defaults)
@PaulF: The second location is correct, all your plugins should go to .wdtvext-plugins folder on USB drive, after a reboot they should be available in OSD. To further debug this have a look at /tmp/wdtvext-plugins (it should reflect your .wdtvext-plugins folder and /tmp/wdtvext-enabled-plugins (should contain symlinks to the enabled plugins) You can also try to execute wdtvext-plugman-web gen to create the symlinks in /tmp/wdtvext-enabled-plugins from /conf/wdtvext-plugins. wdtvext-plugman-web list should list all locally available plugins.
recliq wrote:
KAD wrote:since the topic of plugman got brought up
where is plugman in svn, I'm looking but don't see it https://svn.wdlxtv.com/filedetails.php?repname=1.05.04-wdlxtv&path=%2Flive%2Ftrunk%2Fusr%2Fbin%2Fwdtvext-plugman-web
KAD wrote:it might be a good idea to give some examples of how to use plugman to enable or disable plugins automagically at boot since we've got plugins from within /osd and now from within UMSP plugins Well, the script is quite simple to use. I always wanted to do a wiki page for the plugman scripts but never managed to do so... First of all you need to understand that there are two wdtvext plugin directories in /tmp:
/tmp/wdtvext-plugins /tmp/wdtvext-enabled-plugins
the later contains only symlinks to plugins located either in /wdtvext/plugins (internal plugins) or /tmp/wdtvext-plugins (user plugins). /tmp/wdtvext-plugins is where your .wdtvext-plugins folder located on your usb drive gets mounted, so you normally don't care about it but simply supply your .wdtvext-plugins folder on usb drive.
/tmp/wdtvext-enabled-plugins is handled by wdtvext-plugman-web when executed with the gen option. WDTVExt loads all plugins from this directory. (see /wdtvext/js/main.js and /wdtvext/js/plugin.js)
# wdtvext-plugman-web
usage: /usr/bin/wdtvext-plugman-web [gen|list|listall|repolist|update|enabled|bg-process]
/usr/bin/wdtvext-plugman-web [add|del|download|info|repoinfo] <plugin>
wdtvext-plugman-web add <absolute path to plugin file> and wdtvext-plugman-web del <absolute path to plugin file> basically do exactly what you do in your scripts below. The options list, listall, repolist and enabled are used to list installed/available/enabled plugins. download, info and repoinfo should be quite clear as well... Then there is bg-process, which is executed during boot and collects the available SVN plugins and their info. Last but not least there is the gen option. This is also executed during boot and creates the symlinks in /tmp/wdtvext-enabled-plugins from /conf/wdtvext-plugins.
Since you mentioned the loading of plugins included in osd.bins... There is another maybe interesting fact to the wdtvext plugin loading logic: plugin override If you supply an osd or user plugin which has the same name as one of the internal plugins the system automatically preffers the osd/user plugin and loads it instead of the internal plugin. The priority of the plugins is
- OSD plugin
- user plugin
- internal plugin
So OSD plugins can even override user plugins. (At least that's what I remember right now without diggin through the code.... Don't beat me if it's user plugins overriding OSD plugins )
All plugins listed in /conf/wdtvext-plugins are automatically enabled and boot and loaded on dmaosd start as long as the location given is available at that time (/etc/init.d/S70dmaosd). (otherwise gen fails to create the symlink and the plugin won't be loaded)
Including wdtvext plugins in UMSP wasn't thought of when I (or better we) designed this but I will keep this in mind and try to implement something to automate this like osd plugins, the same should be done for the last missing part then: app.bin.
EDIT: wdtvext-plugman-web doesn't tell much on console, have a look at messages.txt
recliq wrote:
PaulF wrote:
KAD wrote:actually it all looks, fine
just the plugin is not enabled, if it's not in /conf/wdtvext-plugins it's not going to load you should be able to activate it from the wdtvext menu on screen or
echo "/path/to/ShoutcastNowPlaying.plugin.js" >> /conf/wdtvext-plugins
then reboot
That worked, thanks. I committed a change to the shoutcast proxy to write a tmp file send an "x" key. Everything is working now and the current artist and song displayed on the fly. To be save and plugman compliant you can simply do this (as I mentioned in my lengthy post)
wdtvext-plugman-web add /path/to/ShoutcastNowPlaying.plugin.js
This will add your script to /conf/wdtvext-plugins.
This can also be used in eg. the init script of an app.bin to auto-enable the plugin. It will only be added if it's not already in the list. Depending on the time your init scripts runs you may need a reboot though... If you do this before S70dmaosd is run no reboot should be needed.
MediaNavigation requires several patches. You can currently download the svn version and overwrite it with the files in this archive [TODO]. SailorT is in the process of making edits to make the version more functional for 1.05. Mad ady 09:24, 18 March 2014 (UTC)
