What's new
By:
Filters

Another freeze/glitch thread

pabloescaban said:
N lines and CWS lines both have the same details except the port number is different
A N: line can be used in both Oscam and CCcam softcams

If you put CWS line into oscam, it will work but oscam changes it to newcamd and the server is expecting newcamd lines to be connecting via a different port from mgcamd
Click to expand...

WOW
Could you please help me to learn all these kind of things. Just give me a link where all this is available
 
just read through this forum, all the information is here, there's a search bar at the top of each page, type in what you want to know about
 
I'm having problems with glitches as well. The main channels work fine, sky sports, cinema and BT sports.
Box Nation and freeview channels like ITV 4 and Dave started glitching when I renewed my sub and was given a different line.
Why are some channels ok and others not with card sharing? From what I've seen no one does a good service for the music channels for example.

I have emailed the service provider and he says it should be ok now. It's not. I've checked the SNR and it's good but the glitching still happens.
 
Last edited:
heyriggs said:
I'm having problems with glitches as well. The main channels work fine, sky sports, cinema and BT sports.
Box Nation and freeview channels like ITV 4 and Dave started glitching when I renewed my sub and was given a different line.
Why are some channels ok and others not with card sharing? From what I've seen no one does a good service for the music channels for example.

I have emailed the service provider and he says it should be ok now. It's not. I've checked the SNR and it's good but the glitching still happens.
Click to expand...
That sounds like your using a cache server, a cache server stores uses third party servers to get the 'codes' to clear the channel and as the name suggests stores them in a cache, your box is then served with the cached info. This generally works perfectly fine on the popular channels as the cache is refreshed more regularly as it is accessed more, on the minor channels though, if few people are watching then the cache isn't refreshed until the first time someone tries to access it after it has expired, this in turn causes a delay in getting the info back to your box, hence the freezing.
 
grog68 said:
That sounds like your using a cache server, a cache server stores uses third party servers to get the 'codes' to clear the channel and as the name suggests stores them in a cache, your box is then served with the cached info. This generally works perfectly fine on the popular channels as the cache is refreshed more regularly as it is accessed more, on the minor channels though, if few people are watching then the cache isn't refreshed until the first time someone tries to access it after it has expired, this in turn causes a delay in getting the info back to your box, hence the freezing.
Click to expand...

Thank you! This perfectly explains my not so popular and regional channels glitching!

Now... Can I find a provider who doesn't cache??
 
gav28uk said:
Yeah good luck with that. You’ll find the provider hiding under a unicorn, at the end of the rainbow, along with the answer to Brexit!
Click to expand...
not all providers are cache servers, cache servers use other providers with real cards, and those same providers with real cards are available to anyone else, but you pay more for the service.
 
grog68 said:
not all providers are cache servers, cache servers use other providers with real cards, and those same providers with real cards are available to anyone else, but you pay more for the service.
Click to expand...

Yeah I know, my point was the trouble in finding those few honest providers out there who are open about their offerings.
 
pabloescaban said:
try CCcam on oatv6.2, if it's the same i'd have to agree it's probably the hardware
Click to expand...
Just moved back to oatv using WB and oscam, so i'm going to run it for a while and see how it goes. If that doesn't work (which I doubt it will given I tried this same thing only last month) then i'll try CCcam instead. If that still doesn't work I'll have to see if BH and mgcamd works (think Vu's official image is BH so might have some luck?).

It's all a bit odd but it's not a constant issue. It can sometimes go a week without a glitch (or at least no glitches when i'm actively watching the TV) other times it can glitch every 10 seconds for hours. For a long time I agreed with everyone that it was a provider issue (hence why i've got through quite a few providers, and I didn't go for the cheapest ones either), but as I stated a quick swap to a new box with the same line installed and it was fine.

cactikid said:
How good is your cable and what type of splitter,vu are top rated box and cannot see it been a box problem as 4 models i have.
Click to expand...
Only splitter I use is the one that VM provided with the router. One output for the Superhub and another for cable tv. Cable isn't amazing quality (I considered this may be an issue) but as stated in the original post everything was fine on the zgemma during a period in which glitching was happening on the Vu+ box. It's not impossible that the Vu+ tuner is more "precise" and less forgiving of signal issues in comparison to the zgemma, but then i'm just making that up... I don't have the pre-requisite knowledge of how tuners work to make an educated guess on that.


BeakyFord said:
have to agree with most of the responses so far, the VU brand is far superior to the zgemma brand so doubt it is a hardware issue, same with image as you've loaded WB which is known to be a good image, Switching boxes (with same provider & your above findings) rules out a provider issue so all this suggests its a setup issue. Changing CWS to N is an option to try although both should work, are you restoring any setting when loading images? if so try again with a bare bones build & dont restore anything as it could be something in settings that is being restored, also try with only one provider code at a time, triple check your VM splitter/cables & box settings, basically start at the beginning & work forwards one step at a time as its easy to miss something along the way. On the plus side its nice to see someone who has read threads & put the effort in trying to correcting problems before asking for help, you will get there in the end just start from scratch & work slowly.
Click to expand...
Hate to be one of those people that says "I've done all that"... but I think I have...

I only ever restore from a backup when i've tried something and it didn't work. I have an openvix based self-build from when I first set up the box that I keep a backup of, then i'll switch to OATV or someone elses build for a few days to look for improvement, if there's none then I'll restore my backup just because it's got everything setup how I want (when using someone elses build, I generally don't bother tweaking anything as it's a waste of time unless I stick with it).

So i've tried plain re-installs on Vix and ATV, along with a few custom builds such as WB. Therefore by extension i've tried fully loaded builds along with minimal ones. I've tried every oscam example files zip I can find in the first 50 pages of google as well as the TK search (and that's not an exaggeration. I've been trying to fix this since mid-2017 and put 100's of hours into it). And I've read through the oscam wiki and manually had a go at changing each setting that seemed it could be related. Therefore by extension i've once again tried heavily configured oscam config files, along with minimalist ones. Failing someone providing another set of "working config files" that probably won't work but i'll try it anyway, I have explored this avenue as far as I can.

One thing I haven't tried is swapping the line type in oscam over to cccam from newcamd, so I guess i'll give that a shot (although I have tried CCcam software before).


In reply to a few posts saying: VU+ is better than zgemma ... I don't disagree in general. But any manufacturer can have isolated issues. No manufacturer i'm aware of has zero RMA's. Of course I hope i'm wrong given it's an expensive box, but with over 12 months of constant software tinkering it just seems to be pointing towards a hardware issue.

Anyway... I'll see how I get on with a re-test of CCcam on ATV, and then over to BH since the working zgemma uses mgcamd, maybe BH (as much as I don't like it) will provide the solution.
 
Sorry to bring up a slightly old thread, but wondering if you ever got anywhere with this?

I've got a Vu+ Duo 4k box and I'm seeing the same issues. It seems to be channel specific (mostly BBC Scotland for me, but I do see it on some +1 channels).

Getting similar output in the oscam logs:
Code: 
2019/04/12 16:27:50 08412175 c      (ecm) dvbapiau (1841@000000/0000/0C1F/89:24EB172831ABF6E2966560EA4B64C4C4): not found (1 ms) by Provider3 (F/4/4/4) - BBC Scotland HD
2019/04/12 16:27:50 08412175 c   (dvbapi) Demuxer 0 restarting decodingrequests after 0 ms with 1 enabled and 1 disabled ecmpids!
2019/04/12 16:27:50 08412175 c   (dvbapi) Demuxer 0 trying to descramble PID 0 CAID 1841 PROVID 000000 ECMPID 13CC ANY CHID PMTPID 002A VPID 0135
.

Also don't believe it's a provider issue as I've tried various providers. I actually have some old Zgemma boxes and they're using the same provider in some cases (with other accounts), and they work flawlessly. I've bought like 4 different splitters and I don't think that's to blame either. I'm actually using an Asheridge ASH-4P amplifier and the signal quality appears very good on all boxes.

Much like yourself, I've rebuilt the box and tried CCcam etc. Just annoyed that I never returned the box whilst I had the chance.
 
Last edited:
Can you try the following in oscam.server so you have the same line in two readers with one set as fallback. Set client timeout and fallback in the config to something like 3500ms and ensure load balancing or any fancy cache settings you might have from experimenting are turned off (so use a basic config).

I found the glitching is the dvbapi errors like the "restarting decodingrequests" stuff. By having the same details in a fallback reader, it reconnects with that reader and tries again without glitching whenever it gets a "not found". No dvbapi errors then and no glitching.

Worked for me anyway and I tried just about everything else and stumbled upon this today by experimenting! My box is a 4k ARM box too (a Gigablue) running Openvix and the Oscam from the vix feeds. It may not work for your line but worth a try. My line was great with football but complete pants with things like ITV2 HD and Dave HD which pixellated every ten seconds.

[reader]
label = VM1
protocol = newcamd
key = 0102030405060708091011121314
device = server.xyz,port
user = user
password = password
group = 1
caid = 1841


[reader]
label = VM2
protocol = newcamd
key = 0102030405060708091011121314
device = server.xyz,port
user = user
password = password
group = 1
caid = 1841
fallback = 1
 
Boag said:
Can you try the following in oscam.server so you have the same line in two readers with one set as fallback. Set client timeout and fallback in the config to something like 3500ms and ensure load balancing or any fancy cache settings you might have from experimenting are turned off (so use a basic config).

I found the glitching is the dvbapi errors like the "restarting decodingrequests" stuff. By having the same details in a fallback reader, it reconnects with that reader and tries again without glitching whenever it gets a "not found". No dvbapi errors then and no glitching.

Worked for me anyway and I tried just about everything else and stumbled upon this today by experimenting! My box is a 4k ARM box too (a Gigablue) running Openvix and the Oscam from the vix feeds. It may not work for your line but worth a try. My line was great with football but complete pants with things like ITV2 HD and Dave HD which pixellated every ten seconds.

[reader]
label = VM1
protocol = newcamd
key = 0102030405060708091011121314
device = server.xyz,port
user = user
password = password
group = 1
caid = 1841


[reader]
label = VM2
protocol = newcamd
key = 0102030405060708091011121314
device = server.xyz,port
user = user
password = password
group = 1
caid = 1841
fallback = 1
Click to expand...
I may give that a try tomorrow, as i can't get rid of the freezes on my arm box, like you i have tried everything.
 
Boag said:
Can you try the following in oscam.server so you have the same line in two readers with one set as fallback. Set client timeout and fallback in the config to something like 3500ms and ensure load balancing or any fancy cache settings you might have from experimenting are turned off (so use a basic config).

I found the glitching is the dvbapi errors like the "restarting decodingrequests" stuff. By having the same details in a fallback reader, it reconnects with that reader and tries again without glitching whenever it gets a "not found". No dvbapi errors then and no glitching.

Worked for me anyway and I tried just about everything else and stumbled upon this today by experimenting! My box is a 4k ARM box too (a Gigablue) running Openvix and the Oscam from the vix feeds. It may not work for your line but worth a try. My line was great with football but complete pants with things like ITV2 HD and Dave HD which pixellated every ten seconds.

[reader]
label = VM1
protocol = newcamd
key = 0102030405060708091011121314
device = server.xyz,port
user = user
password = password
group = 1
caid = 1841


[reader]
label = VM2
protocol = newcamd
key = 0102030405060708091011121314
device = server.xyz,port
user = user
password = password
group = 1
caid = 1841
fallback = 1
Click to expand...
if you put the same line in the config twice as you suggest your provider server may see this as two connections (multi box) as oscam remains connected, depending on provider this could then in turn lead to the server blocking you. Do it with caution.
 
grog68 said:
if you put the same line in the config twice as you suggest your provider server may see this as two connections (multi box) as oscam remains connected, depending on provider this could then in turn lead to the server blocking you. Do it with caution.
Click to expand...

I did worry about this but my logs show that when the second reader connects, the remote server disconnects the first reader, and vice versa. I.e., it's just like reconnecting on a "not found" (or a timeout) and trying again. This may be different for other lines of course, but should be obvious from the logs. If you DO get two simultaneous connections it might not help anyway I suppose.

By the way, I chose the timeout as 3500ms as it seemed to work well. A lot of channels on my line start returning "not found" and glitching when the ecm times go over about 3.5 seconds but I since changed it back to 5000ms. Much more than that and I started to get the odd freeze.

Finally, this seems to have cured my constant glitching in oscam but I wasn't really getting freezes, apart from obscure channels. If you are, it might not help much in that scenario.
 
Thanks for the reply Boag,

Since I posted I was trying out another provider and have had considerably better luck so far. But I'll maybe give this a bash if any of my other boxes with the old providers have issues.

Cheers!
 
Interested in this post as I too have been having freezing issues on certain channels.Where do you set client timeout and fallback times?
 
On the main config page on web interface, but unlikely to help with freezing, only glitching.
Now that mgcamd is working on most boxes this is a better bet so investigate that. Much less glitching than oscam if your line is less than perfect.
 
Thanks for that Boag-as a matter of interest how do you set reader as fallback? My provider for some reason gave me 3 seperate lines and I have them all entered and still get a lot channels stopping at random and some not working at all.
 
You must log in or register to reply here.
Back
Top