gestern wieder. Nachmitags aus dem Standby 4 Folgen Scrubs auf Pro 7, dann wieder in den Standby, kein Problem. Nachts pro 7 4.15 Uhr "Endlich Sex" nichts ist passiert. Die Log Files sagen, dass der Rechner aufgewacht ist, dann wurde aber nicht aufgenommen und ein paar Minuten später hat er sich wieder schlafen gelegt?!
Das ist ein Asuzug aus dem TV Error Log :
2009-08-30 04:22:17.177000 [14]: TVController:ValidateTvControllerParams - incorrect parameters used! user TvControl.User cardId 5 _cards.ContainsKey(cardId) == False CardPresent(cardId) False
2009-08-30 04:22:17.219000 [14]: bei TvService.TVController.ValidateTvControllerParams(User user)
bei TvService.TVController.IsTimeShifting(User& user)
bei System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
bei System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
bei System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)
bei System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg)
bei System.Runtime.Remoting.Messaging.ServerObjectTerminatorSink.SyncProcessMessage(IMessage reqMsg)
bei System.Runtime.Remoting.Messaging.ServerContextTerminatorSink.SyncProcessMessage(IMessage reqMsg)
bei System.Runtime.Remoting.Channels.CrossContextChannel.SyncProcessMessageCallback(Object[] args)
bei System.Runtime.Remoting.Channels.ChannelServices.DispatchMessage(IServerChannelSinkStack sinkStack, IMessage msg, IMessage& replyMsg)
bei System.Runtime.Remoting.Channels.DispatchChannelSink.ProcessMessage(IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders& responseHeaders, Stream& responseStream)
bei System.Runtime.Remoting.Channels.SoapServerFormatterSink.ProcessMessage(IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders& responseHeaders, Stream& responseStream)
bei System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders& responseHeaders, Stream& responseStream)
bei System.Runtime.Remoting.Channels.Tcp.TcpServerTransportSink.ServiceRequest(Object state)
bei System.Runtime.Remoting.Channels.SocketHandler.ProcessRequestNow()
bei System.Runtime.Remoting.Channels.RequestQueue.ProcessNextRequest(SocketHandler sh)
bei System.Runtime.Remoting.Channels.SocketHandler.BeginReadMessageCallback(IAsyncResult ar)
bei System.Net.LazyAsyncResult.Complete(IntPtr userToken)
bei System.Net.ContextAwareResult.CompleteCallback(Object state)
bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
bei System.Net.ContextAwareResult.Complete(IntPtr userToken)
bei System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken)
bei System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
bei System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)
also ich habe jetzt mal TV server bei den General Settings/ EPG die Timeouts auf 15 Min gesetzt und siehe da es geht. Ansonsten sind allle Schalter alle aktiviert. Habe jetzt drei Nächste was aufgenommen und es hat alles geklappt.
also die Einstellung der Timeouts beim EPG Grabber auf 15 Minuten ist zweifelsohne der Schlüssel zum Erfolg. Ich mache jetzt seit 4 tagen Dauertests. Läuft alles super stabil. Nicht eine Aufnahme wurde verpasst oder nicht aufgenommen. Standby, Aufnahme und dann wieder Standby- Funktioniert.