62 replies to this topic

[Erik Slagter]

Transcoding plugin has disappeared from plugin menu and transcoding doesn't work any longer.

Reread what I just wrote.

 

Did you already do "netstat -lptn".

[wabe]

It's a common misconception that you need a plugin for transcoding. What needs is
- setting up some /proc entries (including enabling the encoders)
- a proxy that listens to port 8002 and 8003 for requests
 
If you do netstat -lptn you'll see the proxies listening.

Not familiar with that particular command so unsure what to look for. There are listeners for port 8001-8003 however
What's supposed to be in /proc?

[Erik Slagter]

/proc (to be exactly /proc/stb) constitutes of the interface between user program's and the drivers. If the encoder is enabled using this interface, it will work. There is no use for a plugin to enable the transcoding when it's already done by startup scripts (see /etc/init.d/transcoding-setup.sh).

[wabe]

So how should I troubleshoot my missing transcoding capability??

[Erik Slagter]

You're probably missing a package.

Try this:

opkg install vuplus-transcoding

and post the output if there is any.

[wabe]

/proc (to be exactly /proc/stb) constitutes of the interface between user program's and the drivers. If the encoder is enabled using this interface, it will work. There is no use for a plugin to enable the transcoding when it's already done by startup scripts (see /etc/init.d/transcoding-setup.sh).

Had a look in /etc/init.d/ it seems that the transcoding-setup.sh is missing the "x" flag.

[Erik Slagter]

No, that is intentional. The scripts are not executed through execve(), they are sourced.

If cat /proc/stb/encoding gives "enabled" the script has run.

Edited by Erik Slagter, 8 March 2014 - 10:34.

[wabe]

No, that is intentional. The scripts are not executed through execve(), they are sourced.If cat /proc/stb/encoding gives "enabled" the script has run.

That commands output 'no such file or directory'
I did rerun opkg install vuplus-trancoding

[Erik Slagter]

No, that is intentional. The scripts are not executed through execve(), they are sourced.If cat /proc/stb/encoding gives "enabled" the script has run.

That commands output 'no such file or directory'
I did rerun opkg install vuplus-trancoding

That should have read /proc/stb/encoder/enabled

[wabe]

No, that is intentional. The scripts are not executed through execve(), they are sourced.If cat /proc/stb/encoding gives "enabled" the script has run.

That commands output 'no such file or directory'
I did rerun opkg install vuplus-trancoding

That should have read /proc/stb/encoder/enabled

Just to ensure that I've executed everything correctly: the command 'cat /proc/stb/encoding' should produce output /proc/stb/encoder/enabled - which is not what I get.
What files should I remove and reinstall to resolve this?
As I previously stated I tried the mentioned opkg remove command but that did nothing

[WanWizard]

No,

 

"cat /proc/stb/encoder/enabled" should produce "enabled" and not "disabled".

[wabe]

No,
 
"cat /proc/stb/encoder/enabled" should produce "enabled" and not "disabled".

It does produce neither. Suspected that /proc/stb/encoding was a typo since there exist a dir /proc/stb/encoder. Running the cat command on this path produce
Cat: read error: is a directory

[Pedro_Newbie]

I'm a bit puzzled, shouldn't be the value in  "/proc/stb/encoder/enable" (mind de lack of the letter d in enable) be the word enable and not enabled?

As I read in /cat/proc/stb/encoder/enable_choices there are 2 choices: enable and disable and not enabled and disabled?

 

Am I missing something, shouldn't the value be enable and not enabled?

[Erik Slagter]

root@duo:~# cat /proc/stb/encoder/enable
enable

 

Copy&pasted so no typos!

 

This is how the output is supposed to look.

[Pedro_Newbie]

Indeed, but the value stored in my Solo2 was enabled instead of enable, I echoed the value by hand into enable no the transcoding works

 

So the script wasn't run I think

[Erik Slagter]

If the script hasn't run, the value reads as "disable".

 

I tried it out, after a reboot the value is "enable" as it should, so the setup-script is actually okay.

Edited by Erik Slagter, 9 March 2014 - 10:25.

[Erik Slagter]

Tried out the transcoding, after a fresh reboot, using mplayer:

 

mplayer http://duo:8002/1:0:...3:EB0000:0:0:0:

 

and it just works. This is Ned 1 HD transcoded to 480p.

 

mplayer has as config options:

 

cache=32768
cache-min=5

[Erik Slagter]

If someone can give me a full example of vlc command + config that doesn't work, I'll try it.

[WanWizard]

Same response here with mplayer as with VLC (netstat confirms there is a service listening on 8002):

 

$ mplayer http://172.16.1.43:8002/1:0:19:1B1D:802:2:11A0000:0:0:0:
MPlayer SVN-r36824-4.8.2 (C) 2000-2014 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing http://172.16.1.43:8002/1:0:19:1B1D:802:2:11A0000:0:0:0:.
Resolving 172.16.1.43 for AF_INET6...

Couldn't resolve name for AF_INET6: 172.16.1.43
Connecting to server 172.16.1.43[172.16.1.43]: 8002...

http_read_response read 0 (i.e. EOF).
STREAM_ASF, URL: http://172.16.1.43:8002/1:0:19:1B1D:802:2:11A0000:0:0:0:
Resolving 172.16.1.43 for AF_INET6...

Couldn't resolve name for AF_INET6: 172.16.1.43
Connecting to server 172.16.1.43[172.16.1.43]: 8002...
read: Operation now in progress

Failed, exiting.
Resolving 172.16.1.43 for AF_INET6...

Couldn't resolve name for AF_INET6: 172.16.1.43
Connecting to server 172.16.1.43[172.16.1.43]: 8002...

http_read_response read 0 (i.e. EOF).
No stream found to handle url http://172.16.1.43:8002/1:0:19:1B1D:802:2:11A0000:0:0:0:

Exiting... (End of file)

[Erik Slagter]

Weird.

 

Can you please send the output of:

 

cd /proc/stb/encoder

cat enable

cd 0

cat profile
cat level
cat display_format
cat bitrate
cat gop_frameb

 

And also dmesg, the driver goes haywire very easily and barfs the logs in that case.

 

Can you also try it with wget and then add the -S option?

 

And as a last resort we might have to use tcpdump/tshark and/or strace