Weak signal > crashing (1 Viewer)
- Thread starter bounguine
- Start date
Sweden
Hi all,
Sorry to re-activate this one. I've just gone live last week Tuesday. Had a nice experience for one evening.
On Wednesday, there was heavy rain, resulting in loss of signal and ... Server crashing.
Yesterday I was at a friends, when my wife was watching CSI. Just when the climax was there, the server gave up. Again a heavy rain shower was the cause.
I had to guide her to remotely connect to the tv server and reboot it entirely. After a week, the WAF has dropped significantly.
(MP Server version is most recent one. Server is XP SP2 + needed patches.)
How to deal with weakening or losing signal?
Sorry to re-activate this one. I've just gone live last week Tuesday. Had a nice experience for one evening.
On Wednesday, there was heavy rain, resulting in loss of signal and ... Server crashing.
Yesterday I was at a friends, when my wife was watching CSI. Just when the climax was there, the server gave up. Again a heavy rain shower was the cause.
I had to guide her to remotely connect to the tv server and reboot it entirely. After a week, the WAF has dropped significantly.
(MP Server version is most recent one. Server is XP SP2 + needed patches.)
How to deal with weakening or losing signal?
Currently TVE3 has CRC check disabled for all the TS packet handling. Please thank to broadcasters who aren't playing nice with the DVB specifications. One possibility to increase the robustness of TVE3 server would be to allow user to enabled the CRC checking for incoming data. Maybe that step should be taken as it is definitely a good way to improve the overall stability when all malformed packets are rejected (of course the code shouldn't crash in the first place when malformed data is received but it is much harder to implement as verification & debugging is pretty time consuming when data must be corrupted randomly and huge data sets should be tested to catch all possible programming errors.).
This is a important issue,
developers: think of all those users we loose because they try MP but think it's too unstable - while the problems are caused by poor antenna/signal.
I've tried to motivate you to fix this bug. (see previous posts)
developers: think of all those users we loose because they try MP but think it's too unstable - while the problems are caused by poor antenna/signal.
I've tried to motivate you to fix this bug. (see previous posts)
Tourettes,
As information from satellites is not comming in OK, checking CRC will often go wrong.
I know about the CRC principle, as I've done IT studies, but don't know about the way it is used in sat transmission.
In the client, there is a debug function, that users can turn on or off. Turning it on generates unstability, so I turned it off. The client is now rocksolid (am still using 1.0.0.0)
For short, I'm not convinced using CRC or other debugging type of approach would be fit for purpose.
SO:
If I take a distance, could the team not just detect malfunctioning in another way?
GIVEN:
1) You are able to detect "no signal" or "no graph" upon tuning.
2) While using manual streaming in the server, the server configurator continuously shows signal strength and quality.
QUESTION: Is it not possible to use that information while timeshift is running (on all the streams, as I'm streaming from 2 receivers, each connected to 4 LNB's)?
If that were possible, you could allow the user to set the level of confidence his system needs for both strength and quality. When the tuning would go below the threshold(s) a still image could be displayed on the client saying "signal to weak" or so.
This would keep the timeshift stream alive, and prevent TVE3 to crash.
WORK AROUND: (that will only work if the server does not take down the client with him):
Currently I'm programming two batch processes
- for the client that will do a remote net stop of the tvservice on the server, wait and do a tvservice start, to put in the main menu
- for the cleint that will do a remote shutdown -r -t00 -f towards the server
It's an ugly solution but at least my wife will not have to spend half an hour being guided to take remote control of the server in the attic.
Next time she might maybe not miss the climax of CSI...
As information from satellites is not comming in OK, checking CRC will often go wrong.
I know about the CRC principle, as I've done IT studies, but don't know about the way it is used in sat transmission.
In the client, there is a debug function, that users can turn on or off. Turning it on generates unstability, so I turned it off. The client is now rocksolid (am still using 1.0.0.0)
For short, I'm not convinced using CRC or other debugging type of approach would be fit for purpose.
SO:
If I take a distance, could the team not just detect malfunctioning in another way?
GIVEN:
1) You are able to detect "no signal" or "no graph" upon tuning.
2) While using manual streaming in the server, the server configurator continuously shows signal strength and quality.
QUESTION: Is it not possible to use that information while timeshift is running (on all the streams, as I'm streaming from 2 receivers, each connected to 4 LNB's)?
If that were possible, you could allow the user to set the level of confidence his system needs for both strength and quality. When the tuning would go below the threshold(s) a still image could be displayed on the client saying "signal to weak" or so.
This would keep the timeshift stream alive, and prevent TVE3 to crash.
WORK AROUND: (that will only work if the server does not take down the client with him):
Currently I'm programming two batch processes
- for the client that will do a remote net stop of the tvservice on the server, wait and do a tvservice start, to put in the main menu
- for the cleint that will do a remote shutdown -r -t00 -f towards the server
It's an ugly solution but at least my wife will not have to spend half an hour being guided to take remote control of the server in the attic.
Next time she might maybe not miss the climax of CSI...
..remember . that if she's timeshifting - and sees the stream stop - it means the stream stopped xx minutes ago (timeshift time) - so restarting server won't help then - it should detect and fix itself ASAP while timeshifting.
Al_Capone,
I think I'm on the same kind of subjective level as you are. Glad you are joining me in my effort.
... So while it detects the low quality or low signal, milliseconds after the quality drops, introducing a still image under a specific threshold, would keep the timeshifting alive ...
- If it takes to long, the users could go back to the tv guide and select another channel (that is received stronger)
- If such a channel is not available, the user could go to a recorded episode, or watch a movie, or listen to music or look at the weather images, or ....
If it would be an AVI or an MPG of the MP man-cat-screen-type-thingy in a loop, it would even make it a nice gag ;-)
That is, of course, if it is at all technically feasible....
I think I'm on the same kind of subjective level as you are. Glad you are joining me in my effort.
... So while it detects the low quality or low signal, milliseconds after the quality drops, introducing a still image under a specific threshold, would keep the timeshifting alive ...
- If it takes to long, the users could go back to the tv guide and select another channel (that is received stronger)
- If such a channel is not available, the user could go to a recorded episode, or watch a movie, or listen to music or look at the weather images, or ....
If it would be an AVI or an MPG of the MP man-cat-screen-type-thingy in a loop, it would even make it a nice gag ;-)
That is, of course, if it is at all technically feasible....
Berns I have to say that you are a little bit off on your comments. CRC checksums are sent with the stream and their sole purpose is to allow application to verify the received data (it works such way even in other than DVB context). There is no other way to detect "the one bit that is wrong in the stream".
Just think how you would be able to detect the "00000001" from "00000011". Both are valid, but it might have invalid data for the context, like telling that some descripor (EPG or any else) lenght is wrong. In that example we could run into memcpy that accesses the memory outside the boundaries it is allowed to access, causing a crash.
Such small change can cause a crash and it wont be visible in any signal level or quality measurements (especially when BDA drivers are known to report false information pretty often, depending on the HW manufacturer).
Just think how you would be able to detect the "00000001" from "00000011". Both are valid, but it might have invalid data for the context, like telling that some descripor (EPG or any else) lenght is wrong. In that example we could run into memcpy that accesses the memory outside the boundaries it is allowed to access, causing a crash.
Such small change can cause a crash and it wont be visible in any signal level or quality measurements (especially when BDA drivers are known to report false information pretty often, depending on the HW manufacturer).