Reply to thread

Message: <blockquote data-quote="mm1352000" data-source="post: 1118906" data-attributes="member: 82144">Hello and thanks for the feedback. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite24" alt="(y)" title="Thumbs Up    (y)" loading="lazy" data-shortname="(y)" />Looks like the IPTV/URL source filter cause TV service to crash when you tried to start watching 220 CSNHD at 19:57:25:[collapse]"1/8/2015 7:57:52 PM";".NET Runtime";"(0)";"Error";"Application: TVService.exeFramework Version: v4.0.30319Description: The process was terminated due to an unhandled exception.Exception Info: exception code c0000005, exception address 54B1DC89";"1026""1/8/2015 7:57:53 PM";"Application Error";"Application Crashing Events";"Error";"Faulting application name: TVService.exe, version: 1.10.0.0, time stamp: 0x548c1072 Faulting module name: MPUrlSourceSplitter.ax, version: 0.0.0.0, time stamp: 0x54aa406b Exception code: 0xc0000005 Fault offset: 0x0000dc89 Faulting process id: 0xdc4 Faulting application start time: 0x01d02b2ecef4504e Faulting application path: C:\Program Files (x86)\Team MediaPortal\MediaPortal TV Server\TVService.exe Faulting module path: C:\Program Files (x86)\Team MediaPortal\MediaPortal TV Server\MPUrlSourceSplitter\MPUrlSourceSplitter.ax Report Id: ebab1056-97a2-11e4-8c7a-1078d2329f27";"1000""1/8/2015 7:58:23 PM";"Windows Error Reporting";"(0)";"Information";"Fault bucket , type 0 Event Name: APPCRASH Response: Not available Cab Id: 0  Problem signature: P1: TVService.exe P2: 1.10.0.0 P3: 548c1072 P4: MPUrlSourceSplitter.ax P5: 0.0.0.0 P6: 54aa406b P7: c0000005 P8: 0000dc89 P9:  P10:  Attached files: C:\Windows\Temp\WER51D8.tmp.appcompat.txt C:\Windows\Temp\WER6F09.tmp.WERInternalMetadata.xml C:\Windows\Temp\WER6F29.tmp.hdmp C:\Windows\Temp\WER8B13.tmp.mdmp  These files may be available here: C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_TVService.exe_2d986b4f398e36c26ceac2284cdfd145d01fcb_cab_0da88d04  Analysis symbol:  Rechecking for solution: 0 Report Id: ebab1056-97a2-11e4-8c7a-1078d2329f27 Report Status: 4";"1001""1/8/2015 7:58:31 PM";"Windows Error Reporting";"(0)";"Information";"Fault bucket , type 0 Event Name: APPCRASH Response: Not available Cab Id: 0  Problem signature: P1: TVService.exe P2: 1.10.0.0 P3: 548c1072 P4: MPUrlSourceSplitter.ax P5: 0.0.0.0 P6: 54aa406b P7: c0000005 P8: 0000dc89 P9:  P10:  Attached files: C:\Windows\Temp\WER51D8.tmp.appcompat.txt C:\Windows\Temp\WER6F09.tmp.WERInternalMetadata.xml C:\Windows\Temp\WER6F29.tmp.hdmp C:\Windows\Temp\WER8B13.tmp.mdmp  These files may be available here: C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_TVService.exe_2d986b4f398e36c26ceac2284cdfd145d01fcb_12ccde2f  Analysis symbol:  Rechecking for solution: 0 Report Id: ebab1056-97a2-11e4-8c7a-1078d2329f27 Report Status: 1";"1001"[/collapse]MediaPortal froze because it was waiting for TV Server to tell it whether tuning was successful or not.Unfortunately your MP logs are at error level, so it is a bit hard to follow this. However, I don't see the second TV Server crash that you refer to.I'm not seeing this in the logs. Maybe this happened in the log gap between 8 and 8:10 PM? BTW, it would be helpful to specify times if you could. Saves guess work.It is entirely possible that tuners would be left in "inconsistent states" after a TV Server crash. Especially a crash involving tuning.TV Server will not use tuners that it thinks might be being used by other software/processes. In particular with CableCARD tuners: TV Server checks if a tuner is playing before attempting to "build the graph" (load the tuner) and/or tune, and if the tuner is playing it won't complete the load/tune process. It looks like this in the logs:[collapse][2015-01-08 20:11:20,197] [Log  ] [20  ] [DEBUG] - DRI CC: PrepareForConnection, connection ID = 0, AV transport ID = 0[2015-01-08 20:11:20,289] [Log  ] [20  ] [INFO ] - DRI CC: remove source filter[2015-01-08 20:11:20,853] [Log  ] [20  ] [INFO ] - Info.: UPnPServerController: GENA disabled for IP endpoint '192.168.1.122'[2015-01-08 20:11:20,858] [Log  ] [20  ] [ERROR] - Exception  :TvLibrary.TvExceptionGraphBuildingFailed: DRI CC: tuner appears to be in use  at TvLibrary.Implementations.Dri.TunerDri.BuildGraph()  at TvLibrary.Implementations.Dri.TunerDri.BeforeTune(IChannel channel)  at TvLibrary.Implementations.DVB.TvCardATSC.Tune(Int32 subChannelId, IChannel channel)[2015-01-08 20:11:20,872] [Log  ] [20  ] [ERROR] - Exception  :TvLibrary.TvExceptionGraphBuildingFailed: DRI CC: tuner appears to be in use  at TvLibrary.Implementations.Dri.TunerDri.BuildGraph()  at TvLibrary.Implementations.Dri.TunerDri.BeforeTune(IChannel channel)  at TvLibrary.Implementations.DVB.TvCardATSC.Tune(Int32 subChannelId, IChannel channel)  at TvService.CardTuner.Tune(IUser& user, IChannel channel, Int32 idChannel)[/collapse]Unfortunately there is no way for TV Server to know that the tuners were playing because a previous instance of TV Server told them to start, and that the previous instance of TV Server crashed before it had a chance to stop the tuners. In other words, TV Server can't bring the tuners back under control until you manually stop them as you did.As far as I can see that "something" seems to be the IPTV filter. I think that fact that it happened while you were trying to switch away from a recording is entirely coincidental.I agree... and as far as I can see, TV Server did tune using other available tuners wherever possible. Note that I don't know of any Ceton tuner locking implementation. The only scenario where TV Server will not attempt to use a Ceton tuner is the self-imposed limitation described above.Regards (and thanks again!),mm</blockquote>

Verification