644 replies to this topic

[albsky]

@Huevos.

I really do not get your point.

Why is it so stupid to ask from a device called Unicable (that is only one cable) to get more than one feed for different tuners.

 

Why is it so stupid to ask your dish to go to one satellite and once you're there use three tuners at the same time?

[Rob van der Does]

I don't understand it either. In fact it's the same as, but more flexible than the '2nd cable from motor' option for a conventional LNB.

[Huevos]

I don't understand it either. In fact it's the same as, but more flexible than the '2nd cable from motor' option for a conventional LNB.

No it is not the same. This is not a second cable, it is one cable that is supposed to be connected to a distribution system to feed all the tuners in a building. The idea of having an LNB that is designed for communal use attached to a motorised dish is ridiculous. What you are asking is special software to be written for people that make bad hardware choices.

[albsky]

 

I don't understand it either. In fact it's the same as, but more flexible than the '2nd cable from motor' option for a conventional LNB.

No it is not the same. This is not a second cable, it is one cable that is supposed to be connected to a distribution system to feed all the tuners in a building. The idea of having an LNB that is designed for communal use attached to a motorised dish is ridiculous. What you are asking is special software to be written for people that make bad hardware choices.

 

May I ask you which is a good hardware choice for three tuner (not for communal use) inside the same receiver?

Three dishes? This is a bad communal choice :-)

[Rob van der Does]

 

I don't understand it either. In fact it's the same as, but more flexible than the '2nd cable from motor' option for a conventional LNB.

No it is not the same. This is not a second cable, it is one cable that is supposed to be connected to a distribution system to feed all the tuners in a building. The idea of having an LNB that is designed for communal use attached to a motorised dish is ridiculous. What you are asking is special software to be written for people that make bad hardware choices.

 

Yes it is the same (not meaning 'identical').

The 'second cable from motor' does two things:

1- Loop through the signal (internally or externally) and making E2 aware of (the limitations of) the loop through (i.e. for a conventional LNB only the same 'quadrant').

2- Tell E2 that it can only tune the second tuner to the same satellite as the first one.

 

Exactly the same is required for an Unicable LNB in a motor (plus of course the normal Unicable related stuff).

And I think it's ridiculous that (presently cheap) Unicable LNB's can't be used for a motor (at least not for more than one tuner), while a far less potential conventional LNB can.

 

And this is not related to the rest of the in-house distribution; this is only about one of the possibly more cables (depending on the local Unicable setup) to tuners of one of the receivers in the house.

Remember the one cable coming from a motor could be used in a far more potential way when it would allow for Unicable setups comparable with the 'second cable from'. Not a bad choice, not bad at all.

Edited by Rob van der Does, 29 August 2016 - 16:43.

[Huevos]

The point of a unicable LNB is to supply as many tuners as possible. If you then aim it at the wrong place in the sky (with you motor) all those tuners go offline. What is the point in that?

[Rob van der Does]

You look at it the wrong way, but I'm running out of words repeating myself.

I have a motorised dish, with one cable leading into the house. I want to make as much use of that as is possible. Now what do you think gives me more options: a conventional LNB. limiting the second tuner to the same quadrant as the first tuner, or an Unicable LNB allowing me full access to all transponders? I fail to see anything wrong in that.

I really don't see what it is you fail to understand from my simple explanation...

[Huevos]

Why would you want to run a crippled setup? Cable costs me 9€ for 100m. My suggestion is you get some and add a second run rather than having these self imposed restrictions.

[Rob van der Does]

OK, I'm out of here. You're really hopeless.

[johnfr]

hello

 

error with installing usbserial for smargo on my vu+ solo 4k and openpli

opkg_install_cmd: cannot install package

[Dimitrij]

openpli 4 vusolo4k


vusolo4k login: root
root@vusolo4k:~# opkg list *usbserial*
enigma2-plugin-drivers-usbserial - 1.0-r0.0 - enigma2-plugin-drivers-usbserial version 1.0-r0  USB serial drivers
enigma2-plugin-drivers-usbserial-dbg - 1.0-r0.0 - enigma2-plugin-drivers-usbserial version 1.0-r0 - Debugging files  USB
 serial drivers  This package contains ELF symbols and related sources
 for debugging purposes.
enigma2-plugin-drivers-usbserial-dev - 1.0-r0.0 - enigma2-plugin-drivers-usbserial version 1.0-r0 - Development files  USB
 serial drivers  This package contains symbolic links, header files,   and
 related items necessary for software development.
kernel-module-usbserial - 3.14.28-r1.2.0.5 - usbserial kernel module  usbserial kernel module; USB Serial Driver core
root@vusolo4k:~# opkg install kernel-module-usbserial
Installing kernel-module-usbserial (3.14.28-r1.2.0.5) on root.
Downloading http://downloads.pli-images.org/feeds/openpli-4/vusolo4k/kernel-module-usbserial_3.14.28-r1.2.0.5_vusolo4k.ipk.
Configuring kernel-module-usbserial.
root@vusolo4k:~#

[Satpal]

Thanks a lot! I encountered the same issue a while ago but didn't bother as I didn't really need it at the time. But there are two things at least I don't really get here: Why isn't the kernel module part of the image as it is for the other receivers? Shouldn't there be at least an error message that you can make sense of, "missing dependency" would be helpful?

Having the usbserial driver in the plugins but not the necessary kernel module for it makes no sense unless it's installed with it by default.

[johnfr]

openpli 4 vusolo4k


vusolo4k login: root
root@vusolo4k:~# opkg list *usbserial*
enigma2-plugin-drivers-usbserial - 1.0-r0.0 - enigma2-plugin-drivers-usbserial version 1.0-r0  USB serial drivers
enigma2-plugin-drivers-usbserial-dbg - 1.0-r0.0 - enigma2-plugin-drivers-usbserial version 1.0-r0 - Debugging files  USB
 serial drivers  This package contains ELF symbols and related sources
 for debugging purposes.
enigma2-plugin-drivers-usbserial-dev - 1.0-r0.0 - enigma2-plugin-drivers-usbserial version 1.0-r0 - Development files  USB
 serial drivers  This package contains symbolic links, header files,   and
 related items necessary for software development.
kernel-module-usbserial - 3.14.28-r1.2.0.5 - usbserial kernel module  usbserial kernel module; USB Serial Driver core
root@vusolo4k:~# opkg install kernel-module-usbserial
Installing kernel-module-usbserial (3.14.28-r1.2.0.5) on root.
Downloading http://downloads.pli-images.org/feeds/openpli-4/vusolo4k/kernel-module-usbserial_3.14.28-r1.2.0.5_vusolo4k.ipk.
Configuring kernel-module-usbserial.
root@vusolo4k:~#

 

thank a lot but don't work

 

reader) smargo [smargo] ERROR: Opening device /dev/ttyUSB0 (errno=2 No such file or directory)
2016/10/20 18:49:47 0CA8DFFE r   (reader) smargo [smargo] Cannot open device: /dev/ttyUSB0
2016/10/20 18:49:49 0CA8DFFE r   (reader) smargo [smargo] ERROR: Opening device /dev/ttyUSB0 (errno=2 No such file or directory)
2016/10/20 18:49:49 0CA8DFFE r   (reader) smargo [smargo] Cannot open device: /dev/ttyUSB0

 

 

and scan usb

 

 

USB Devices

Bus 005 Device 002: ID 148f:5372 
Bus 008 Device 002: ID 0403:6001 
Bus 001 Device 001: ID 1d6b:0002 
Bus 002 Device 001: ID 1d6b:0003 
Bus 003 Device 001: ID 1d6b:0002 
Bus 004 Device 001: ID 1d6b:0002 
Bus 005 Device 001: ID 1d6b:0002 
Bus 006 Device 001: ID 1d6b:0002 
Bus 007 Device 001: ID 1d6b:0001 
Bus 008 Device 001: ID 1d6b:0001 
Bus 009 Device 001: ID 1d6b:0001 
Bus 010 Device 001: ID 1d6b:0001

[Satpal]

Doesn't really belong in this thread anymore, but you should try:

 

protocol = smartreader (or smargo)

device = 008:002

 

or

 

protocol = mouse

device = /dev/ttyUSBx

 

but you can't mix protocols and devices that don't work together.

[johnfr]

Doesn't really belong in this thread anymore, but you should try:

 

protocol = smartreader (or smargo)

device = 008:002

 

or

 

protocol = mouse

device = /dev/ttyUSBx

 

but you can't mix protocols and devices that don't work together.

 

protocol = smartreader (or smargo)

device = 008:002

 

work fine

thank a lot for your help

[mkkaczy]

Hello to everybody, as it is my first post here.

Just wanted to to ask. Is there any chance to get MgCamd working on the solo4k in PLI? Are you working on it? I just switched from Duo (Mgcamd) to Solo 4K (oscam) and it seems that Ocsam has some better and worse days, while Mgcamd worked always simple and stable.

[Erik Slagter]

If you can find whoever wrote mgcamd, ask them to compile it for arm. Good luck!

[Huevos]

Right now, as far as I know, the only cam for ARM processors is Oscam.

[Dimitrij]

Hello to everybody, as it is my first post here.

Just wanted to to ask. Is there any chance to get MgCamd working on the solo4k in PLI? Are you working on it? I just switched from Duo (Mgcamd) to Solo 4K (oscam) and it seems that Ocsam has some better and worse days, while Mgcamd worked always simple and stable.

Edited by Dimitrij, 1 November 2016 - 18:19.

[Huevos]

Where are these from? Are they part of PLi build?