Optware for WDLXTV Live

[recliq]

get opt.bin provided by b-rad and all is fine... (it's in this thread)

[ch1ptune]

Thx recliq.. I was using the wdlxtv_optware.app.bin. Everything seems to work much better now.

I have one problem, though. With wdlxtv_optware.app.bin, SABnzbdplus worked perfectly well. I did have some trouble getting it to start automatically at boot, so I figured that the opt.bin provided by b-rad might solve this particular issue. Having configured SABnzbdplus the exact same way (with concern to host and port) as before, I'm puzzled by the fact that SABnzbdplus no longer works. It listens on port 8080 for just a second, but when I try to reach it from my laptop it disconnects and disappears from the list of processes running on my WD TV Live.

Has anyone had the same issue?

Thanks in advance.

/ch1ptune

[dzebrys]

hi,

i think this opt.bin provided by b-rad is reason of problems with SCOD.
this week i've changed original [from first post] wdlxtv_optware.app.bin
to opt.bin and then got into trouble with SCOD.

my config is wdlxtv live 1.0.21_4.5.3 ext3 connected to synology nas ds211 through
nfs. i've rw mount option as well as some additional settings to support jumbo frames
[gbit ethernet backbone]. that was worked like a charm till friday night. no problems
with starting various video formats even when nas in sleep mode. some libs from
wdlxtv_optware.app.bin /opt/lib has been overwritten by me using the original one
from /lib to get screw of problems with mc, perl and moviehash [internal MediaNavigation].
as i remember for sure it was libthread and libdl.

after removing previous /opt and installing b-rad opt.bin the good thing at first sight was
no problems with shared libralies. but then SCOD appeared. dmaos.log point that at begining
of file play there is some data base update made to file in .wd_tv directory. searching forum
for similar problem pointed to commonly known issue with SCOD when RW mounting option is
activated. as for me the main advantage of playing around with custom firmware are wdtvext
plugins and ability to downloading and converting subtitles to srt format on-the-fly [using little
tunned MediaNavigationV4RC2] i've decide to revert to previous setup. removed optware and
vuala - no SCOD, RW nfs mount working.

imho some lib from optware is responsible for SCOD and this is not original firmware inherited
bug. could anyone point what is happening when .wd_tv database is updated and which shared
libs takes part in it?


regards
piotr

[b-rad.cc]

your rw nfs mount is the reason for the SCOD, as has been documented a thousand times.

[dzebrys]

hi b-rad,

literaly, when opt.bin mounted i was unable to play any video file sourced from nas, SCOD.
after opt.bin removal&restart it works. in both cases nas is nfs RW mounted.

when in home i'll send you logs from reproduction.


regards
piotr

[dzebrys]

hi,

have some time to reproduce problem and it seems much clearer now.

opt.bin is almost ok*.

the SCOD was due to missing nolock option when mounting nfs AND using opt.bin.

my [corrected] nfs mount cmd looks like:
xmount 192.168.1.12:/volume1/pub bubik nfs rw,hard,intr,nolock,tcp,vers=3,rsize=32768,wsize=32768

*strange is why problem appeared. the behaviour of db update after starting media file differs depending
on configuration.

1) no opt.bin mounted, nfs without nolock
the ph_ad_entry updating usb connected ext3 volume

ph_add_entry[752], name: 127.Hours.2010.avi, path: /filmy/fabula/127.Hours.2010.DVDSCR.XViD.ABSURDITY, uuid: bubik
mount_port =/tmp/media/usb/USB2
ph_add_entry[762],dbfile= /tmp/media/usb/USB2/9443a6e1-6da6-4a32-a5b1-06ea6cd1f7d4//.wd_tv/ph.db
ph_add_entry[802],update playback history Access: 1, Spent time: 3.56
MediaMark: [onPageEnter]

2) opt.bin mounted, nfs without nolock
the ph_add_entry stucks trying to write to nfs volume

ph_add_entry[752], name: 127.Hours.2010.avi, path: /filmy/fabula/127.Hours.2010.DVDSCR.XViD.ABSURDITY, uuid: bubik
mount_port =/tmp/media/usb/USB2
ph_add_entry[762],dbfile= /tmp/media/usb/USB2/bubik//.wd_tv/ph.db

3) opt.bin mounted, nfs with nolock
the ph_ad_entry updating nfs connected volume

ph_add_entry[752], name: 127.Hours.2010.avi, path: /filmy/fabula/127.Hours.2010.DVDSCR.XViD.ABSURDITY, uuid: bubik
mount_port =/tmp/media/usb/USB2
ph_add_entry[762],dbfile= /tmp/media/usb/USB2/bubik//.wd_tv/ph.db
update_playback_history[330], This data dont need to insert. Skip it.
ph_add_entry[802],update playback history Access: 1, Spent time: 0.38
MediaMark: [onPageEnter]

does anyone could explain why the db update destination differs depanding on if opt.bin is mounted or not?

i hope this nolock option will heal SCOD for others also. please spread this info to forum.


regards
piotr

[jaromil]

besides current debugging.... i'd like to ask you dev guys a final opinion about this optware for LIVE (instead of rw ext3 fw): do you think is worth continuing?

most reports are negative about reaching full functionality and myself i've verified is almost impossible to have everything working. my wrapper + mount -o bind approach *almost* did it but doesn't reaches a stable state and i think it will never reach it

so with your final blessing i'd now like to discontinue this LIVE version of optware and support only the ext3 fw based, eventually developing further on that (the opt.bin can be made smaller and the installer nicer)

what do you guys think?
ciao

[RMerlin]

I haven't had the chance to take a look at it, but I'd say having even a mostly functional implementation of Optware is a good thing. So far it seems to still be useful as some people are using it, so the limitations might not be deal-breakers - just need to make sure they are documented.

[jaromil]

ok. i just wanted to avoid overload of debugging messages from users due to confusion between ext3 and live optware.

i'll keep maintaining optware live and eventually merge fixes, but i guess the disclaimer should always be clear:

the optware for ext3 is more stable and it should be used in case something doesn't works correctly in the live version.

i have just updated my devices to 0.4.7.3: will test this app.bin on them and report here documenting more in detail on the first post of this thread.

another nice thing that i can do is adapt a nicer installed for the ext3 optware and make its package smaller...
since B-Rad is active on the new 1.04 firmware i think is good to offload his work on optware.

keep it up!

[recliq]

Just my 2 cents:

Why have optware as two seperate packages (opt.bin and app.bin version)?
I think we should stick with opt.bin version, not only because it works with non ext3 filesystems...