Project

General

Profile

Bug #1377

Problem with TBS 6984 and TBS 6981 from rev 3.3.110

Added by Kjell A. Stormo about 8 years ago. Updated about 8 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
DVB
Target version:
Start date:
2012-10-31
Due date:
% Done:

100%

Estimated time:
Found in version:
3.3.110
Affected Versions:

Description

Unable to map service to channels.
Works in rev up to rev 3.3.78, but got quite a few Continuity counter error
Do not know if these errors are related to driver or tvheadend.


Files

tvh-log.rtf (142 KB) tvh-log.rtf Kjell A. Stormo, 2012-10-31 22:13

Associated revisions

Revision 03ff9727 (diff)
Added by Adam Sutton about 8 years ago

Fix #1377 - check for EOVERFLOW when reading from DVB device.

This can be returned as a result of a failure to read quickly enough from
the DVR device. This appears to happen quite regularly on channel zap for
certain cards. It's non-fatal and the system will auto recover immediately.

For now I've left the exit on other error in, but have added an error
message so we know its happening (the biggest problem was this was happening
silently before).

This may also relate to #1134, so might be worth back porting to 3.2.

Revision 144ec7dd (diff)
Added by Adam Sutton about 8 years ago

Fix #1377 - check for EOVERFLOW when reading from DVB device.

This can be returned as a result of a failure to read quickly enough from
the DVR device. This appears to happen quite regularly on channel zap for
certain cards. It's non-fatal and the system will auto recover immediately.

For now I've left the exit on other error in, but have added an error
message so we know its happening (the biggest problem was this was happening
silently before).

This may also relate to #1134, so might be worth back porting to 3.2.
(cherry picked from commit 03ff9727564d991b40e0f0fb0bb3ea06d00d8e65)

History

#1

Updated by Vojtech Plavecky about 8 years ago

Definitelly not a drivers problems, i have that issue too, adn im pretty sure thats not an cabeling, dish pointing and etc related. Continuity errors appears, but im not sure when its start.

btw if u have a problems to zap, check if there is sat conf and service provider in adapters, muxes tab. they use to dissapear.

#2

Updated by Kjell A. Stormo about 8 years ago

I think this might be the same issue as bug "1134"
and going throug forum it seams like more people have the same problems or issues quite like this one.

#3

Updated by Adam Sutton about 8 years ago

  • Status changed from New to Need feedback
  • Assignee deleted (Hein Rigolo)
  • Priority changed from High to Normal
  • Target version deleted (3.3)

I don't know that this is the same issue as #1134, though there may be some correlation. I'm still working with Alin on his problems related to that issue and we're trying to investigate whether the IRQ mods help.

However this issue seems to be reporting a change in recent functionality, where as #1134 reports a problem that has always been there. Also though there are plenty of users who are happily using TBS6984's without any problems.

However the specific case in #1134 (and possibly this issue?) is that the usage is very different to that of a normal user, since the cards are being used to service an IPTV system and therefore TVH is also having to do an awful lot of data shovelling (plus some processing of course) that might be related to the problems.

Adam

#4

Updated by Kjell A. Stormo about 8 years ago

Ok, i did see that he was pushing a bit more data than usual.
I am also going to push some streams, but not until the system is stable, hereby two two times 4 sat input = 8 input, this can normally push tv to 10 - 12 frontends, depending a bit of channel and transponder.
Latest change on my system:
I have put the TBS adapters to MSI mode, it helped a bit.
i have also reverted back to tbs driver 120216.
I am not shore, but think it have been a bit more stable.
still get a lot of Continuity code error, but only on some channels, and adapters ( but not always the same adapter and channel)
So still a bit unstable.

And of course not able to use tvheadend ver above ver 3.3.78 here i still get the same problem as before.

And if it will help, please reply my mail, and ill give you access, if it helps.
then you might compare systems with the same cards, an maybe put in some probes if that will help sorting out some errors.
I am not that experianced in linux, so it takes a lot of time for me to figure out howto and where to find usefull info regarding both HW and SW problems :-)

#5

Updated by Kjell A. Stormo about 8 years ago

I just experienced some other stuff....
I lost signal on two transponders, they have been up and streaming tv for 8 hours witout any problem.
then just started to loos signal slowly, getting more and more continuity code error.
then the signal was comletly gone, and the client got 0 banwidt.
I stopped all clients hwo was getting signal from that adapter, put the signal meter on, and it dropped to 0 on the two transponders. after 20 minits it was back to 100 %. I have done nothing to the machine, no reboot no nothing, now it's streaming out tv like nothing has happend.....
And it was only the transponder that i was getting signal that went dead, all the others were at 100 %

And all adapters get exatly the same signal, same cables and from the same multiswitch.
I use a 12 output multiswitch an also pushing signal to two normal pvr decoders. no problem with the signal on them.

#6

Updated by Kjell A. Stormo about 8 years ago

Just an update.
Have experienced the latest problem with several frequencies, after watching the same cannel for 3 -4 hours the signal drops to 0, if the client goes to another channel on a different frequens the signal comes back to 100% on the previous channel and then i get the channel back. ( Ver 3.3.78 tvh)

#7

Updated by Adam Sutton about 8 years ago

  • Status changed from Need feedback to Fixed
  • % Done changed from 0 to 100
#8

Updated by Adam Sutton about 8 years ago

  • Affected Versions 3.2 added

This might also affect 3.2, so might back port the fix.

#9

Updated by Kjell A. Stormo about 8 years ago

Does this mean that i now can download the lates git code and it will work?

#10

Updated by Adam Sutton about 8 years ago

This means you can download the latest git code and it "might" work ;)

I finally got around to syncing my timeshift fork (which is where I've been doing dev for a while) with master to pick up the full mux changes and so I finally hit the problem myself (I've got a 6981). After a few hours of digging (due to my lack of useful error messages!) I finally found what was causing it to fail on my system.

So hopefully this will fix it for you as well.

Adam

#11

Updated by Kjell A. Stormo about 8 years ago

Ok, i'll try getting the new master later tonight. If the problem's not solved, will it help you to have a look at my system? mail me if so, ill open a port for you.

#12

Updated by Adam Sutton about 8 years ago

  • Target version set to 3.2

The specific problem relates to older versions as well so will be back ported to 3.2.

#13

Updated by Vojtech Plavecky about 8 years ago

faint signals again on muxes working in the morning, afternoon are faint, morning mapped afternoon can just delete.

#14

Updated by Adam Sutton about 8 years ago

I don't understand that last comment?

Are you saying your still experiencing problems with muxes reporting bad signal levels when you wouldn't expect it?

Adam

#15

Updated by Kjell A. Stormo about 8 years ago

Some what yes.......
Running the 3.3.134 ( thhink it was) After 6-8 hours running the machine just broke down...Fatal ERROR

After rebooting it, and after a kouple of hours the pickture was slowly getting more and more destorted, and mosaik like....
The signal i'm not shore what strength it had, (had not enabled meassuring) but after a little while the picture got lost from the adapter, and when trying to reconnect, the client went back to the same adapter every time i tried, while other clients had good signal and picture on other adapters, and 2 or three other adapters where free.
One improvemet i notised was that the x.x.134 had little or almost none CC Error.

But due to fatal errors, i have reverted to ver 3.3.126~ga9692b9. Here i have about 500 CC Eror for hours running one one channel, but still running :-)
Starting recordings and it stil works. but when using 5 - 7 adapters, the overflow of CC Error kills TVH.

Kjell

#16

Updated by Kjell A. Stormo about 8 years ago

After running a few hours more, this issue still remains!
Rev 3.3.126
Loosing signal on some adapters, but only on one of the LNB's, so it seams that some of the adapters stopp switchin between the LNB's
I do not know if this is the reason this happends, or if there is other issues related to this.

This also results in a problem that clients still hammers on the failing adapter, and does not move on to the next available one.

Kjell

#17

Updated by Vojtech Plavecky about 8 years ago

just turn off autodetect muxes, and tick skip initial scan. its quite better now, but from time to time some mux appears like faint, after zapping is allright. i will bet on it that some other routine is taking adapter and zapping mux and for that reason its not availaible for detect/scan/idle scan and for that reason tvh is changing status to faint even if mux is allright.

Also available in: Atom PDF