INTERACT FORUM
Windows => Television => Topic started by: Mans on July 07, 2017, 03:07:50 pm
-
Seems the latest build aka .17 bit broke Sat->IP TV :(
Yaobing, i've made you a logfile, please find attached.
The crash did occur when changing to another channel after some 10 seconds.
Did roll-back to .13 and voila, back working.
Have tested a second time, just to make sure the update went fine, but still not working with .17
In case you would need additional info or me to test something, let me know :-)
Thanks.
-
Your log doesn't contain any indication of an actual crash. Maybe you can elaborate what exactly happens?
-
Hi Hendrik,
The latest build, .17, broke Sat->IP TV.
When trying to skip to the next channel MC was stopped by Windows as been inresponsive.
I went back to the previous build, .13, and Sat->IP is back fine.
My two other zones/clients have never been updated to .13 and so did continued playing TV channels.
If i can check or verify something, let me know :-)
Steven.
-
Have you tried re-installing build 17?
I don't know what to make of this, but I see the following failure:
0004984: 9796: Reader: RTSPReader: Sending request: SETUP rtsp://192.168.2.110:554/?fe=2&msys=dvbs2&src=2&freq=11856.0&pol=v&mtype=qpsk&sr=29900&pids=0,2530,516,35,88,516&x_pmt=2530/ RTSP/1.0
CSeq: 3
User-Agent: LIVE555 Streaming Media v2016.02.09
Transport: RTP/AVP;unicast;client_port=65332-65333
0004984: 9796: Reader: RTSPReader:
0004984: 9796: Reader: RTSPReader: Received 35 new bytes of response data.
0004984: 9796: Reader: RTSPReader: Received a complete SETUP response:
0004984: 9796: Reader: RTSPReader: RTSP/1.0 404 Not Found
CSeq: 3
0004984: 9796: Reader: RTSPReader:
0004984: 9796: Reader: RTSPReader: [URL:"rtsp://192.168.2.110:554/?fe=2&msys=dvbs2&src=2&freq=11856.0&pol=v&mtype=qpsk&sr=29900&pids=0,2530,516,35,88,516&x_pmt=2530"]: Failed to set up the "video/MP2T" subsession: 404 Not Found
-
Hi Yaobing, yes i did made a second attempt to install .17.
But without any succes.
I was also today the post of TimoBeil95 which have the same issue with Sat-IP.
Only a blank screen, waiting for a lock.
I'm back to .13 and fine till further update.
If i can be of any help, or you want me to test anything, shoot man.
Goodluck.
-
Rebonjour Yaobing,
Hi man, may i ask if you found what caused this sudden 'break' of the Sat-IP functionality within .17 ?
Let me know if i can be of help or test something for you.
Goodluck !
-
Please try this DLL (https://www.dropbox.com/s/an9d8p3fprv9hl8/JRTelevision.zip?dl=0).
Install the latest MC23 build (23.0.17) if you have not done so already. Download, unzip, and copy JRTelevision.dll into MC23 installation folder.
-
Hello Yaobing, thank you for your reply :) Reinstalled MC and then copied the dll to the directory. But unfortunately the old message apperas. Waiting for signal lock....
Have the log attached...
Regards
-
Sorry Yaobing, thanks but same overhere :(
"No lock", blank screen.
I did checked the status of the DD OctoNET Sat->IP server and the requested stream is launched, incl a locked tuner, continues to run but as it seems not been 'collected' by MC.
Thanks on keeping us posted, so we can check and test :-)
Goodluck !
-
For some reason we are not able to get the audio streams.
Please try again with this DLL (https://www.dropbox.com/s/xnv11uq4ub1e5rg/JRTelevision.zip?dl=0). I adjusted some logging and hope it will reveal something.
-
Hi Yaobing, done and attached you can find the 'fresh' log.
Goodluck !
Steven.
-
Thanks for your help. I found a bug that caused the problem.
Please try this DLL. (https://www.dropbox.com/s/v7uy9ktk5be99eo/JRTelevision.zip?dl=0)
-
Yes Yaobing !
This new DLL did the job :-):-):-)
Small feedback, have the impression that swapping channels takes a bit more time now ?
I'm used now to verify the stream build with VLC player and seems to switch faster, maybe just my feeling :-°
Looking forward on future features within MC :-)
Have a nice day !
Steven.
-
yapp,
Thank you Yaobing, it does now work!!!! Thank you very much for your work!!!.
But I have some problems with channel switching, Sometomes the ac3 stream is not being grabbed, instead I have to select another ac3 stream manually and switch back to the previous ac3 stream. Another feature request would be, to set a default stream or is this already available?. Because when I start a channel, it's often the wrong stream. Also it would be nice to select the audio stream via the OSD with a remote.
Regards
-
If I switch from an mpeg channel to an ac3 only channel, the problem occurs. If I then select the ac3 stream in the audio programs menu, it works, although, the channel is already marked for use.
After this procedure, channel switching in ac3 only channels is no problem. But when selecting a channel with mpeg audio, the problem is again there.
-
Default stream selection is already implemented and will be available in the next public build.
-
Yaobing, thank you very very much!!!!!!!. Very cool option with the default stream, but one problem:
Although I can now set the default stream, there occurs a problem when switching from an mpeg channel (some channels do not send in ac3 in Germany) to an ac3 channel or to a channel where the ac3 audio pid is the default pid.
I have attached a log file. Switching from 3sat (mpeg) to arte (ac3). Then no sound. I have to reselect the audio stream and then it works. Switching from ac3 to mpeg is no problem. only the other way round
EDIT: The problem occurs also, when MC is started. Starting a channel with an ac3 stream from scratch doesn't work. So I have again "just" reselect the already checked audio pid, just have to click on it in the audio programs menu ----> sound
-
Great day Yaobing,
Always work in progress :-)
Concerning my remark of yesterday; i've been playing around a bit to get things verified.
It had to do with the fact the Sat-IP server was found via directly by the client. This instead over the MC server.
For now it seems when addressing the tuner(s) in direct by each client you win a bit in switching time.
(The OctoNET interface then also shows the IP if each client instead of eachtime the MC server's address)
The above isn't logic and should not be done, my guess, as the logical around time-shifted recordings and recordings in general is destroyed.
Thanks Yaobing and keep on the good work :-)
-
Just noticed .19 been posted Yaobing, for me same issue as before with .17.
Doesn't seem to grab to SAT->IP streams.
Went back to .17 & your adapted DLL for TV.
Let me know if i can be of any help.
-
I just copied the modified dll over the installation of .19 ----> works
-
I believe that fix is in the next build, which should be available in a couple of days:
23.0.20 (7/12/2017)
3. Fixed: Sat>IP television stopped working in recent builds.
-
perfect :)
-
Yaobing, I have forgotten to attach the log, with the problem of switching from ac3 to mpeg channels
-
Hey Yaobing, do you have a clue, why the channelswitching problem does occur. Do you need more log files? Then, no problem :)
Regards
-
I am working on something else at the moment, but I think I do have some clues. I will work on it later today.
-
Please try this DLL with MC23.0.21 (https://www.dropbox.com/s/neetgxs2kh6oh6x/JRTelevision.zip?dl=0). Install MC23.0.21 first, then copy this DLL.
-
Hi Yaobing, Timo,
I've installed the tuned .DLL.
But still some issue when switching AC3 to MPEG1 channels.
MC stops when trying to switch back after the channels hangs.
Log is 6000kb, even after i've cleared it some minutes ago ?
Yaobing did the loggings is doing something much more as before ?
Let me know if i can be of help or if i can send to you ?
-
You may be able to send the 6 MB log by email. yaobing at jriver dot com
-
Hi Yaobing,
PM sent.
Have a nice day.
-
Hi Yaobing,
PM sent.
Have a nice day.
The log shows that you played a few channels with MPEG-1 or MPEG-2 channels. Among these channels "Crime Investigation" seemed to have trouble tuning. Then you switched to Discovery HD, which presumably has AC3 channel. A crash occurred, apparently in LAV filter. I will ask Hendrik about it. However, I should mention that the crash occurred before the AC3 channel stuff had trickled down to the LAV filter yet. So it may be just switching among different MPEG audio channels that triggered the crash.
-
Hi Yaobing, appreciated !
Thanks on keeping me posted about this particular issue.
I should also add i've noticed this crashing before when switching the same channels.
So i guess nothing to do with .21 into particular.
-Timo or others; did somebody experienced such a 'scenario' also ?
Thanks !
-
Hello Mans, hello yaobing,
with the new dll channel switching does work. The no sound problem at the start of MC and during channel switching from mpeg 1 to ac3 does now work. Only sometomes MC crashes completely with the windows typical error message, "the programm doesn't work anymore". But this is only sometomes and I havent found out yet, what is causing the crash. Maybe it's the same issue from mans.
I will try to reproduce the error.
Thank You!
-
Greatday gents, Yaobing,
A quick message to ask if you've found or noticed something about the topic above ?
Please let me know if I can be of help or test something ?
Good luck !
-
Guys
Been watching this thread as I am keen to add a sat ip server (probably the Triax TSS400). Is MC ready to deal with it now? And, how will it work if I already have a HDHomerun terrestrial server on the network already. Can MC deal with both at the same time?
Thanks for any advice..
Rob
-
Greatday gents, Yaobing,
A quick message to ask if you've found or noticed something about the topic above ?
Please let me know if I can be of help or test something ?
Good luck !
Regarding the crash after switching channels, I asked Hendrik about it but he was not able to identify the cause using the crash dump you supplied.
When the next build of MC is released, please try again to reproduce the crash and capture a set of logs.
-
Guys
Been watching this thread as I am keen to add a sat ip server (probably the Triax TSS400). Is MC ready to deal with it now? And, how will it work if I already have a HDHomerun terrestrial server on the network already. Can MC deal with both at the same time?
Thanks for any advice..
Rob
MC should be able to handle streams from any Sat>IP server. The only issue, other than the occasional crash discussed here, is that we still require that the server outputs an M3U channel list (and put the location of that file in the server's description xml so MC can find it and load it).
By "HDHomerun terrestrial server", do you mean DVB-T served by a Sat>IP server? If so we should be able to handle that too (but no one tested it). If you mean a plain DVB-T tuner (as HDHomerun is), then there is no conflict at all. MC would have a set of DVB-T channels for the existing HDHomerun, and a set of Sat>IP channels for the added Sat>IP server.
-
OK Yaobing, i will keep you posted after i've installed the upcoming build.
Logs and feedback will be sent then.
Thanks !
-
MC should be able to handle streams from any Sat>IP server. The only issue, other than the occasional crash discussed here, is that we still require that the server outputs an M3U channel list (and put the location of that file in the server's description xml so MC can find it and load it).
By "HDHomerun terrestrial server", do you mean DVB-T served by a Sat>IP server? If so we should be able to handle that too (but no one tested it). If you mean a plain DVB-T tuner (as HDHomerun is), then there is no conflict at all. MC would have a set of DVB-T channels for the existing HDHomerun, and a set of Sat>IP channels for the added Sat>IP server.
Good news then, thanks. There isn't a huge choice of sat >ip servers, particularly in the UK where they don't seem that popular. Could we compile a list of those that will work by creating the m3u list? I have an HDHomerun Connect which is a DVB-T twin tuner to ip server. It works superbly with MC, my problem is a huge tree which interferes with my terrestrial signal. I know my sat signal from Astra (Freesat in the UK) is a more stable signal.
MC finds the two tuners via network and for the most part gives a brilliant (HD) picture, except when the weather deteriorates and the signal fluctuates and causes breakup and pixellation. Its not that often, but enough to make me look for a sat based solution. EPG, recording etc all work superbly.
-
Great day Yaobing, Timo,
Q; anyone also lost their EPG ? I've had EPG set-up as MC2XML and worked fine. Even i've struggled to have my Guide showing up under Theater View.
But now it seems i've lost grabbing new data.
MC UI tells me the EPG was updated but no new data was included ?
I've added a log for you Yaobing, maybe something is in...
I don't know if it's related to Sat>IP or not, otherwise it's maybe off-topic.
PS i've went back to .19 as also reinstalled MC23 but nothing comes thru anylonger.
Thanks for your help.
-
It appears to be a EPG server issue. Sometimes a server would just stop updating and might not resume updating for days.
-
Thanks Yaobing, you're right.
I've just set-up a second service, this time an external XMLTV Grabber (WebGrab+) and bingo, the EPG is back filled.
Seems like MC2XML is offline since a couple of days, as my Guide was completely empty yesterday.
All good now :-)
-
Great to know you have found a solution.
-
Hi Yaobing,
Log have been send to you concerning the before mentioned crash of MC or atleast of the render.
Running .61 x64 fyi.
This time not during channel switch but when double-clicking the preview window in TV Guide.
Full screen/Theater View did opened but crashing the renderer.
Thanks !
-
Hi Yaobing,
Log have been send to you concerning the before mentioned crash of MC or atleast of the render.
Running .61 x64 fyi.
This time not during channel switch but when double-clicking the preview window in TV Guide.
Full screen/Theater View did opened but crashing the renderer.
Thanks !
I got your email, thanks. Unfortunately the information did not help much. Next time please send MC log (https://wiki.jriver.com/index.php/Logging).
-
Thanks Yaobing. The strange thing it was the application itself which generated the log file. Not MC. First I've noticed it.
Ok next time I'll take the log from MC as well.
Thanks.
-
Hi Yaobing,
I've mailed you another logfile.
Too big as attachment to post it here.
"MC stopped working".
This time the trigger wasn't the view switching in Theatre View.
Watching a channel after selecting it from the Guide, but again in Theatre View.
Had some seconds for perfect content, then sudden closed down.
Thanks for your help,
Hoping the log indicates something.
-
Thanks for the log files. I was able to see the crash in the log but I am still not able to determine what caused it. :(
I see the following:
1. A recording was started at around 8:10 pm
2. A second recording was started around 8:30 pm
3. You started watching the second program, at around 8:54 pm.
4. The first recording was stopped at around 8:55 pm
5. crash occurred with the tuner you were watching (and recording).
I was surprised that the crash happened with the second tuner, not the first, as I saw some odd things happening with the first. It was dropping data, as if it was not able to handle the data fast enough.
How did the recording of the first program come out? Have you tried playing it? Does it have a length of about 45 minutes?
The crash happened in a thread where streaming data was received from the server.
-
Great day Yaobing,
Thanks for your feedback,
-I've verified both these recordings and they are perfect and complete.
-Yes the first recording has a runtime of 45min.
Something most be going on as I'm noticing this issue already since the start of V23.
Since encrypted Sat->IP is supported.
I've added you some background here - for your idea:
I do run from time to time all four tuners. Both recording and/or viewing.
We've got 3 clients around the house running MC.
A thing I've noticed as well, sometimes at the start-up of Live TV or when switching a channel, the feed isn't showed.
Then MC goes automatically to the next channel and feed is immediately on screen.
Like some timeout kicked in - problem with locking a feed ? Some confirmation isn't achieved between Tuner and MC-server ?
At such a moment i can notice the stream at the Sat->IP server is output' and data is running.
Even in VLC player the stream can be opened.
The complete system is onto a GigaBit Cisco switch. Never noticed any other network or buffer issue.
Even MC streams BluRay iso's and DVD's thru the house without any issue.
The MC server has 8GB of DDR4 on board, powered by an i7 CPU.
So I'm guessing this isn't the bottleneck.
Yaobing in case you want me to do some tests let me know.
Thanks man.
-
Great day to you Yaobing,
May i ask if you found something about this issue which is causing MC to crash in some case ?
-Lately I've been monitoring the streams inside the network - between the Sat->IP server, MC Server and the Clients.
It seems the OctoNet server outputs the requested stream(s) pretty fast and constant.
->The most stable scenario is when all clients do request there stream directly from the Sat->IP server itself.
-Guessing it has something to do with the additional time/delay which MC Server adds - causing some timeout -> finally the next channel will be requested and shown by the system or crashing at the end.
Yaobing what about the idea of splitting-up both buffer and recordings folder locations ?
Maybe it's something to test - at least I'm in - certainly in Sat->IP server setup's,
-I'm just thinking if such could be done, the each client can have its own live-buffer. And request it's own 'client' stream from the Sat->IP server.
-The dedicated 'TV recordings' folder is the one where all recordings are stored and monitored in order to update it's 'shared' library.
->As I'm thinking a time-shifted file belongs to the 'client' only not to the server, again my guess :-)
->Downside could be the additional space needed at the client side in order to buffer it. But then again this data would be more limited and prob deleted at the end.
Apart from this do you think it would cause some issues when having both locations split-up ? Maybe only assignable when having Sat->IP configured ?
-A Request from a client for an instant recording which is been time-buffered ? Hmmm.
Thanks in advance for you insights and help Yaobing :-)
Enjoy the weekend.
-
Great day to you Yaobing,
Concerning my issue where a sudden crash would happen, I'm guessing i did found the 'cause'.
Yesterday I've build a new W10 X64 client onto a 7i7 NUC.
When using the 'supplied' Iris 650 graphics driver no crashes happened.
Then i noticed my other NUC's have a newer version of Intel Graphics.
When updating also the new NUC to the latest driver, my system immediately crashed when starting a TV channel in Theater View.
Rebooted the system and made a second attempt, again a total crash - but only when using Theater View.
Finally downgraded the Graphics driver again and stable since.
-And last-but-not-least what's your idea about splitting both the Live TV buffer and Recording location ?
Does such make any sense to you - but again only for SAT->ip is the request.
Thanks !
-
-And last-but-not-least what's your idea about splitting both the Live TV buffer and Recording location ?
Does such make any sense to you - but again only for SAT->ip is the request.
On a single computer, the live TV buffer and the TV recordings should not be separate, especially when recording in JTV format. Using the live buffer as the recording is the whole idea of JTV.
If I understand you correctly, you are actually talking about an MC client computer relative to an MC server. Current situation with MC is that all clients can have access to their own local tuners and network tuners (such as Sat>IP) for live viewing. They can not be used for recording. Recording can be done only on an MC server, or on a stand-alone computer. In the future we may allow clients do recording using their local tuners or network tuners, under certain conditions.
-
Great day Yaobing,
Clear and you've nailed my question indeed.
Thanks for your toughts and view about the future :-)
And indeed i do run multiple MC clients which are all using the SAT>IP server.
It's just I've noticed you win time when each client handled its stream and recordings by itself instead of 'over' MC Server.
So if we could test at a certain moment 'local' recordings it would maybe make sense to have an individual checkbox if these local recording should stay local or always 'shared' by the MC server's library.
Like p.e. recordings made or instructed by the client inside the children's room -> not shared by the MC server towards other clients. Or off-course the opposite: recordings instructed by parents :-)
Another thanks for your p.o.v. and help.
Steven.
-
If you want a recording stay local and not shared, you can simply change that machine's library to Local Library and run it as an independent machine. When a computer is connected as a client, it uses the server's library. Therefore any recording, if enabled, must be shared.
-
Thanks Yaobing and indeed complete thru.
I will move over the clients towards their local library over the weekend ;)
-
Great day Yaobing,
Please find attached a new logfile.
I've rapported a while ago some change of channels would cause MC to crash.
Such a hard crash didn't happenend to me anymore.
Except of a crash of the onboard Intel HD Iris 650 Graphics.
Just before such would happen I'm getting a red error message of MadVR into the left upper corner.
Fyi i'm exclusively using the Digital Devices Sat>IP set-up.
Second issue:
In the log you can notice a couple ch swaps:
-When locking into the 4th channel the image freezes.
From the Digital Devices Interface i can see the stream is still active and running.
When moving to the previous channel the switch happens, but the image STAYS frozen.
MC showes a 'play' status from it's OSD.
Now I did just discovered from looking to my desktop, the MadVR icon changes then to a 'paused' state.
When clicking on 'play' in the MadVR tool the image resumes and everything is back fine.
Third:
A couple of secs later in the log you found switching back to this 'CAZ' channel all is fine and the previous and next channels do continue to play aswell.
But then some additional channels swaps and the sound isn't started.
When switching to the previous ch again, the sound reappears.
The 2ND and 3Th issue can be reproduced on several channels but not on every case, but random happens.
I've tried to combine these issues, as I'm guessing they're related to eachoder.
Thanks for your feedback and in case i can test or help some 'build' please let me know Yaobing.
Steven.
-
Could it be that the Intel graphics are just not powerful enough to run MadVR? I tried with a NUC (HD530) and a Kaby Lake i3 (HD630) and although both would run Red October HD (Mad VR) for a few minutes, ultimately both would crash causing symptoms like you describe.
Try dialling it down to Red October Standard and see if you have the same problems.
I was under the impression that no on board GPUs are powerful enough for ROHQ, and a seriously powerful discrete card would be needed.
-
Hi Robt,
Thanks for your input man,
I've been monitoring the On-board GPU for a while, seems to be balancing between 60 - 70%.
I'm not saying the 7i7bxx NUC with Iris 650 is a lot overpowered.
8GB of ram, 30% of average useage.
CPU around the same percentage.
Following your suggestion I'm now running SQ instead of RO HQ.
Let me monitor the situation during the next couple of days.
Thanks,
-
I tried monitoring my CPU and GPU with HW Monitor and although things looked ok, it would always crash after a few minutes playback.
Interested to see if running ROS makes any difference.... keep us updated how it goes.
-
Great day,
As suggested I'm using now RO SQ instead of HQ since the last couple of days.
This seems to be helping on 2 out of 3 issues.
No more crashes or frozen images after channel a switch.
The onboard GPU inside the 7i7 NUC isn't powerfull enough to support ROHQ/MadVR at all times.
-But the audio which isn't present after a channel swap is still the case.
When the channel switches the sound stays muted and will only be active when another channel is selected.
The affected channel isn't never the same, switching to previous or next channel solves the issue.
So still trying to figure out what's causing the audio from following the video.
Thanks.
-
I am still trying to figure out what to do about the glitch at channel switching.
-
Good to hear the crashes have stopped.
A question for you. How much has reducing ROHQ to ROS changed your video quality?
-
Hi Robt,
ROHQ gave me a more fluent image.
On standard i do notice some shuttering when watching live-tv.
Less when watching movies.
Once i discover more about the topic i let you know.
Thanks Yaobing for your further research.
-
Do you use 64 bit version or 32 bit version?
The reason I ask is that I would like you to test a new dll.
Please install the latest build (81) from the MC32 board. Then download one of the following:
64-bit DLL (https://www.dropbox.com/s/ma88ciusmfcrxww/JRTelevision%2064bit.zip?dl=0)
or
32-bit DLL (https://www.dropbox.com/s/2ft4c6ljylnqb16/JRTelevision%2032bit.zip?dl=0)
Unzip, and copy JRTelevision.dll into MC installation folder.
-
Can I try this?
What are you hoping it fixes?
-
Hi Yaobing,
Thanks for your input and reaction.
I've installed this new dll:
After restarting MC (.81) i had a win10 full crash, BSOD with a notification about some non compatible video thing.
Windows rebooted automatically and now - so far so good, I've tried some 20 changes changes, random and so far the audio is constant and following the video stream.
I do notice a slower change between channels. Something like 1-2 seconds slower as before.
Has this somethong to do with the changes you've made on this updated dll ?
Thanks for your help.
-
Sorry Yaobing, i didn't noticed your question to me about which platform I'm using: But I'm using the x64 version on all 3 of my builds since JRiver introduced it :-)
Since then MC's performance went up :-)
Thanks.
-
Can I try this?
What are you hoping it fixes?
This patch tries to fix the issue with audio or video freeze during channel switching, like this:
But then some additional channels swaps and the sound isn't started.
When switching to the previous ch again, the sound reappears.
-
I do notice a slower change between channels. Something like 1-2 seconds slower as before.
Has this somethong to do with the changes you've made on this updated dll ?
I don't think the change would introduce such a large delay.
-
I will do some more testing over the weekend and report back to you.
So far so good and the audio seems to track the video when changing TV channels (OctoNet Sat>IP)
At this stage i've only updated the dll on one machine, so i can now verify the time needed to switch channels against another client.
Thanks.
-
Great day all, Yaobing,
Following the above, the issue we're the audio stream isn't started after some TV channel switching seems to be solved with the updated dll.
Even i still get the feeling the channel swap does take like a second extra now.
But another issue occured, i'm not sure how it's linked, but the same channel which had the most consequent problem with the audio is since then sometimes displayed with thick black stripes.
We're talking about 50% of the image whch gets blacked. Just one specific channel and not everytime.
Running .81 with the updated dll and ROS.
Restarting MC, rebooting the client doesn't solve thisone.
Any idea or hint ?
Another thanks !
-
When you used the word "client", I guess you were talking about MC as a client to Sat>IP server, not MC as a client to another MC. If it were MC client to an MC server, channel changing is known to be slow.
Could there be a signal issue with some of those channels?
-
Great day to you Yaobing,
Thanks.
Bad reception, not the case. As when selecting the next and then immediately going back to this specific channel = perfect image = ok.
Thru all MC machines seems to talk directly to the Sat>IP server = best result, most stable and fastest.
'Before' i did notice 2 seconds to swap TV channels, recently I'm noticing 3-4 secs.
So my first guess was the updated dll. Still running the initial firmware on the Sat>IP server.
Update: when writing this feedback, i do remember i did changed my settings from JTV to TS.
Maybe this is causing the added delay ?
But as mentioned before I'm still noticing all recordings are in JTV format instead of TS. I've got to manually convert them to TS, by library tool, in order for ComSkip to work.
Then the only really slow moment is the initial start-up of a TV, which can take up to 10 seconds or even an time-out for the selected channel and at the end the next channel will be displayed.
Refuring to a clean start of MC.
Another thanks for your input.
-
Hi Yaobing, just for you information, as I'm trying to find what causes MC to keeps recording in JTV format instead of TS (ComSkip compatible) I've reinstalled MC onto the 'Server' and rebooted everything.
Launched a TV recording, but still no TS file ?
Do you have any idea?
I've run the set-up as TS and also checked the recording setting: TS.
I need to manually run 'covert format' in order to get ComSkip to see the file.
As I'm using a Sat>IP server i think TS is native to the stream and easier to handle/record aswell.
Thanks.
-
send me a log.
-
Here you go Yaobing, I've first cleared the log - started a recording for 30 secs - and stopped.
Hoping you're able to notice something.
Thanks.
-
Please try this DLL (64-bit) for TS recording format. (https://www.dropbox.com/s/841yuc0detrl2oi/JRTelevision%2064%20bit.zip?dl=0)
-
Hi Yaobing,
BINGO man, with the use of us DLL the TV recordings are using the TS format :-)
Some further testing like swapping channels etc is onto my scheduele for this evening :-)
I'll keep you posted sir.
-
All recent changes will be in an upcoming new build (84 or higher).
-
Great day to you Yaobing,
As followup on the situation where I'm noticing some issue with my Sat>IP tuners when launching 'TV' or when switching channels:
I've made several captures with WireShark and asked the technical contact from Digital Devices again to evaluate.
He's carefully as maybe pointing out the following:
The implementation of the following command which MC send towards the Sat>IP server in order to request a stream: 'fe=1&'
P.e. is it possible that the Tuner 1 (FE=1) etc is already in use at the moment ? Referring to the following request:
256 OPTIONS rtsp://xxx.xxx.x.xxx:554/?fe=1&msys=dvbs2&src=2&freg....
307 SETUP rtsp://xxx.xxx.x.xxx:554/?fe=1&msys=dvbs2&src=2&freg....
89 Reply: RTSP/1.0 404 Not Found.
257 OPTIONS rtsp://xxx.xxx.x.xxx:554/?fe=2&msys=dvbs2&src=2&freg....
308 SETUP rtsp://xxx.xxx.x.xxx:554/?fe=2&msys=dvbs2&src=2&freg....
89 Reply: RTSP/1.0 404 Not Found.
256 OPTIONS rtsp://xxx.xxx.x.xxx:554/?fe=3&msys=dvbs2&src=2&freg....
132 Reply: RTSP/1.0 200 OK.
307 SETUP rtsp://xxx.xxx.x.xxx:554/?fe=3&msys=dvbs2&src=2&freg....
209 Reply: RTSP/1.0 200 OK.
And his hint was correct, both tuners were occupied: MC Server was recording and another Client was playing a channel.
He also mentioned without FE the Sat>IP Server use the next free tuner.
Yaobing if i can capture, test or log something please shoot :-)
I do thank you in advance !
-
This is very useful. Thanks.
-
Additional for Yaobing:
https://tvheadend.org/issues/4619
http://www.dvbviewer.tv/forum/topic/58808-cannot-connect-to-rs-using-satip/
Not sure it's helpful in any way, but at least it come up during a 'Sat>IP fe' session on Google ;D
-
When the error occurred, which channel was the MC server serving and which channel was requested? MC would have avoided the tuner that was in used, unless the new request is the same channel as the tuner is already tuned to.
-
Yes Yaobing the request channel was the same as the recorded one.
I've made you some additional test and mailed you a couple of screenpics :-)
Thanks for your feedback.
-
OK. That makes sense. We do specify "fe=" because we try to manage tuner selection ourselves. I am aware that the server can do it for us, but that would require me to code Sat>IP very differently from the other tuner types, which would not be a good idea.
While the server is recording a particular channel, and a client request the same channel, we use the same tuner. Somehow we send those commands unnecessarily. I will check it out. In the mean time, can you capture a set of logs and send them to me? Let the server record on a channel, then let a client request the same channel.
By the way, the duplicate entry in your pictures seems to be created because the client was requesting live channel. The server creates a temporary jtv file to serve a client. When the client stops playing the extra file will eventually disappear (probably not immediately though).
-
Hi Yaobing,
I'm preparing a Dropbox send as too big to include or even mail.
I did mailed you an filtered version, but not interesting I'm guessing.
So the full capture will be send over Dropbox :-)
Included will be a WireShark capture.
4 recordings and some switching to live by a client.
Thanks man.
-
Please include MC logs.
-
Can you describe the problem in more detail? When MC server is recording on a particular tuner, what do you do on a MC client to cause a problem? Or was it an independent instance of MC trying to tune to a channel?
-
Yes Yaobing,
Just made you a new log:
-Tuned onto ch 1: Eén.
-Started to recording this show.
-Switched during watching 'live' this channel Eén to the next channel : Canvas.
-Black no image and after some secs error message.
-Automatically the following channel was tried: VTM, then same error after some secs.
-Finally the 4th channel is switched in to and bingo the 4th channel gets a lock and image.
This is happening in 1/10 times.
Then Wireshark shows me the stream error as copied into my error post.
Thanks man.
-
Yaobing, here's also a second log when the channel has been selected but only sound is played, no image.
As long you keep the playback and even after switches to other channels the image stays black.
Only a stop and new 'watch' brings back the image.
Such issue isn't happening a lot, have seen this more recent.
Not sure it's only related to TV.
Maybe a more general video glitch ?
Log attached.
Thanks.
-
Great day Yaobing,
Hi, after sending you both logfiles, did you noticed something of interest inside ?
If you need me to trace some further things, let me know.
Goodluck and another thanks in advance.
-
Yes Yaobing,
Just made you a new log:
-Tuned onto ch 1: Eén.
-Started to recording this show.
-Switched during watching 'live' this channel Eén to the next channel : Canvas.
-Black no image and after some secs error message.
-Automatically the following channel was tried: VTM, then same error after some secs.
-Finally the 4th channel is switched in to and bingo the 4th channel gets a lock and image.
This is happening in 1/10 times.
Then Wireshark shows me the stream error as copied into my error post.
Thanks man.
All of these happen on a client machine? And the tuners are directly accessible on the client? In other words, when you watch a channel, you are accessing the tuner from the client, not via the MC server.
-
Hi Yaobing,
Yes both these logs are from the MC Client 'living'.
The instructed Recording as also the Live viewings were from the same client.
Onto the 2nd client @ 'the master bedroom' we notice the exact same issues.
All clients do use the MC Server library.
EPG, channel index, TV Recordings etc are configured on the MC Server.
At start-up the clients do connect to the MC Server.
Each client seems to receive the requested stream from the Sat>IP Server due the streampaths which are available to each device.
Confirmed to me by looking into the Sat>IP server streaming overview. As i notice the IP-adress from each client as also from the Server in case of recordings.
Fyi the MC Server runs onto a machine at the storage and only accessible via Remote Desktop. No monitor. No playback.
A 3th client runs as audio-only mode = zone 2 or second floor audio.
Hoping my explanation does makes sense to you ?
In case of any question shoot or in case a Teamviewer session could clear things out let me know :-)
Thanks.
-
While I search for a solution, you can try putting the tuners in different order on different computers. That will reduce the chance of collision.
-
Hi Yaobing, thanks.
This would mean configuring the MC clients. Something which I didn't touched at the moment. The clients gets all info from the MC server...
Please confirm.
Thanks for the help.
-
There are some things on clients that are specific to clients. Tuner ordering is one of them.
-
OK will do this over the evening.
Thanks for your work and in case you've something to test don't hesitate ;D
-
Hi Yaobing,
I've reordered the TV Tuners since yesterdayevening no more collisions happens.
I'm guessing the 'fe' hint from DD was somewhere into the right direction.
Just a short feedback, the black screen issue do still occurears.
No ticable on both Clients used for Live TV.
In case such happens, only a stop can solve this. Changing channel or pausing don't recover the video.
The audio is always playing fine.
Then something else which I've been noticing over time:
The guide (EPG) does displays from time to time a 'green play icon' even while nothing is playing.
I've just checked both the MC Server and the Sat>IP server, while this happend.
A short log is attached, started just in order to capture this 'moment'.
I'm mailing you some screenpics, hoping all of this is somehow helpful to you.
Thanks again !
-
The Green Play Icon typically means that the item was last played in MC, and still appears in Playing Now, where it will be bolded as it is still the selected item (and locked by Windows it based on my observations). It displays even if the item isn't currently playing, until Playing Now is cleared, or something else is played.
I don't recall seeing it in either the Theatre or Standard View EPG displays though, and I can't make it happen just now.
-
Great day !
Thanks RoderickGI,
Yes I'm referring to Theatre View.
The green 'playing' icon stays active from-time-to-time even the playback was stopped.
Once noticed, i did went to Standard View to check the tuner status in MC, all tuners where 'idle'.
Then checked the status of both the streams as tuners on the Sat>IP tuners, nothing opened or tuned.
I've mailed Yaobing some screenshots indicating the above.
This issue isn't something important, but maybe there's something linked with the repported issues I'm noticing when tuning Sat>IP tuners.
Sir Yaobing did you noticed something on this ?
-I can confirm the reordering of the tuner lineup, as you've suggested, has done the job.
No more collisions since then, but still noticing the missing video/image from time to time when switching channels. Then only a stop can bring back the video. Audio plays fine.
I'm guessing due the re odering a 'Watch Live' request for the same channel as the one already on Recording brings a second tuner to be used. This instead of sharing the already opened stream/tuner.
If i can be of help, test something, please let me know.
Thanks !
-
I am working on these things, but have not made significant progress on either.
-
Yaobing, maybe interesting:
The clients doesn't seems to rapport the Tuners status correctly.
Under Show Status at Client 1 it shows all four tuners as idle.
And actually 2 out of 4 were in use.
When looking into MC Server i can notice one tuner been used for a recording.
The second client doesn't rapport the actual recording neither, only the tuner used by itself.
As the signal level is also missing from the OSD.
I'm guessing the status and additional feedback, like signal q, isn't collected from the RTSP.
Maybe this info is helpful somewhere.
-
Yaobing, maybe interesting:
The clients doesn't seems to rapport the Tuners status correctly.
Under Show Status at Client 1 it shows all four tuners as idle.
And actually 2 out of 4 were in use.
When looking into MC Server i can notice one tuner been used for a recording.
The second client doesn't rapport the actual recording neither, only the tuner used by itself.
As the signal level is also missing from the OSD.
I'm guessing the status and additional feedback, like signal q, isn't collected from the RTSP.
Maybe this info is helpful somewhere.
That is what I have been working on. Each instance of MC, be it a server of a client, is treating these tuners as independent local tuners. They only check the status of the tuners as seen within the program, because the tuners are treated as local. In an upcoming new build I am hoping this will change.
-
:D :D :D