Jump to content

[DEV]New Argus Provider


pünktchen

Recommended Posts

Hi Griffo, do you by any chance still have this .ts buffer file present? Would be good to analyse why ffmpeg is having issues reading it.

Link to comment
Share on other sites

Hi Sven, is it possible that the stream isn't kept alive properly which tranlates in ffmpeg stating that the file either can't be read or has invalid data in it?

Edited by Rudig
Link to comment
Share on other sites

Hi Sven, is it possible that the stream isn't kept alive properly which tranlates in ffmpeg stating that the file either can't be read or has invalid data in it?

 

I think they may be happening. I tried to capture the .ts file but it is barely created when Argus deletes it.

 

From the ARgus Logs

 

 

2014-11-02 09:29:24.3644 [info ][3]: AddStream: file = "c:\timeshift\Card4-1-0.ts.tsbuffer", stream= "rtsp://VAULT:8554/stream-live-4-1"

2014-11-02 09:29:27.5050 [info ][3]: RemoveStream: rtspUrl= "stream-live-4-1"
2014-11-02 09:29:31.5207 [info ][3]: AddStream: file = "c:\timeshift\Card4-1-0.ts.tsbuffer", stream= "rtsp://VAULT:8554/stream-live-4-1"
2014-11-02 09:29:33.3019 [info ][3]: RemoveStream: rtspUrl= "stream-live-4-1"

 

 

Argus and MB logs attached

GriffoLogs.zip

Link to comment
Share on other sites

Hi Griffo,

 

Not sure if this is possible but can we get the most extensive logging from Argus? Perhaps it states in logging which proces terminates the stream

Link to comment
Share on other sites

Thanks for these files, in the recorder_REST.log it seems a heartbeat is in place for a stream

 

2014-11-02 20:21:15.6215 [info ][19]: REST PUT /Callback/Heartbeat/1e580c63-52db-11e4-80bc-38eaa7abfd4c

 

 

But that stream doesn't appear anywhere in the other logging. Also the stream which is active doesn't seem to have a heartbeat active.

 

@@Sven, could this be the issue? No heartbeat thus a dieing stream which in turn makes it impossible to transcode since there is nothing to transcode?

Link to comment
Share on other sites

Thanks for these files, in the recorder_REST.log it seems a heartbeat is in place for a stream

 

 

But that stream doesn't appear anywhere in the other logging. Also the stream which is active doesn't seem to have a heartbeat active.

 

@@Sven, could this be the issue? No heartbeat thus a dieing stream which in turn makes it impossible to transcode since there is nothing to transcode?

 

The heartbeat is not sent to argus?

Link to comment
Share on other sites

@@Sven,

 

If I look into the REST API of Argus I see the following:

 

 

Post/KeepLiveStreamAlive
Keep live stream alive
Description

Tell the recorder we are still showing this stream and to keep it alive. Call this every 30 seconds or so.
Post Data

Post data is the live stream entity of the stream to keep alive.Parameter Format Description
Channel Channel The channel being streamed.
RecorderTunerId Guid The ID of the recorder this stream is running on.
CardId string The unique ID of the recorder's card that is being used for the streaming (if provided by the recorder).
RtspUrl string The rtsp URL to the stream.
TimeshiftFile string The UNC path to a timeshift file of the live stream (if available).
StreamStartedTime /Date(gmt_ms+HHmm)/ The date and time the stream was first started.
StreamLastAliveTimeUtc /Date(gmt_ms)/ The date and time the stream was last sent a keep-alive signal (UTC).

Show JSON example
Returns

Returns true if the live stream is still running, false otherwise.
Show JSON example

 

 

Is this keepalive action done by you?

 

@@Griffo, can you traceback in your logging, who started stream 1e580c63-52db-11e4-80bc-38eaa7abfd4c?   Was that mediabrowser or just a scheduled job within Argus?

Edited by Rudig
Link to comment
Share on other sites

Yes i do that. But i am changing some stuff. To do it on a more proper way...

Edited by Sven
Link to comment
Share on other sites

The problem with timeshifting is the container "tsbuffer". I think @@Luke told me a while ago that this was not yet possible..

It's "tsbuffer" because it could me more files.

 

A recording is "ts" and that is not a problem. The "LAG,blocks,.." on the rtsp is also a good question.

 

But i am not a real transcoding expert, so...

Link to comment
Share on other sites

The ts buffer file can indeed be switching to another file so perhaps rtsp is the way to go. From what I read about ffmpeg it should be able to use rtsp as input, but I've never tried that.

 

edit1:

 

Tried to use the RTSP stream from Argus as input for FFMPEG, and it worked :-) really cool to be honest.  I copied the RTSP string that Argus gives in the RTSP logfile into my FFMEG parameters and it started to use that as input. Works pretty well. Hopefully we can test this some more and use this to bypass the tsbuffer file issues 

Edited by Rudig
Link to comment
Share on other sites

You can test it. By unchecking the timeshift option.

That is/was already rtsp.  But we have many LAG,blocks on that...

Link to comment
Share on other sites

As i can see in your transcode logs, you are using timeshifting.

But that doesn't work (he doesn't know the tsbuffer format)

Link to comment
Share on other sites

pünktchen

Mmh, but when i look in the plugin settings again the checkbox for timeshifting is not active :wacko:

Nevertheless with or without this option, it makes no difference. The stream starts and stops immediately.

 

To be more exact it starts and always stops twice! (start-stop-start-stop)

 

A question apart from streaming problems:

Every time i restart MBS the guide is empty although i have deactivated the task to clean the tv database.

Isn't there a cache?

Edited by pünktchen
Link to comment
Share on other sites

@@Sven,

 

If I look into the REST API of Argus I see the following:

 

 

 

Is this keepalive action done by you?

 

@@Griffo, can you traceback in your logging, who started stream 1e580c63-52db-11e4-80bc-38eaa7abfd4c?   Was that mediabrowser or just a scheduled job within Argus?

 

I've attached new logs below. To avoid any confusion, i deleted all scheduled recordings, and restarted both Argus and MB3 to get fresh clean logs. Nothing else is being done on these boxes as they are a test setup. So whatever is in the logs is from me clicking on LiveTV in MB in Chrome.

 

Just to touch on FFMPEG - personally I could care less about live transcoding of live TV, give it to me as a raw stream please and let my server CPU cycles do something more useful. If you could do that, then I could finally get rid of MediaPortal and just use MBT for everything (once it's stable that is). I've noticed that currently MBT tries to get transcoded TV rather than raw currently.

GriffoLogs.zip

Link to comment
Share on other sites

Griffo thanks again for these logs.

 

Couple of strange things appear, stream is started and within a second its also stopped: 

 

 

from recorder.log

 

 

2014-11-03 13:04:26.4109 [info ][Recorder]: TuneLiveTvStream(): tuning card #4 to SBS ONE
2014-11-03 13:04:26.4265 [info ][Recorder]: Starting live stream on card #4, service SBS ONE in 'c:\timeshift\'
2014-11-03 13:04:31.0203 [info ][Recorder]: Live streaming of SBS ONE started on card #4, stream 51e1c305-5ec0-4588-9405-bf2dc79003ab
2014-11-03 13:04:32.8640 [info ][Recorder]: Stopping stream 51e1c305-5ec0-4588-9405-bf2dc79003ab on card #4
2014-11-03 13:04:33.0828 [info ][Recorder]: Stream 51e1c305-5ec0-4588-9405-bf2dc79003ab stopped

 

Heartbeat is sent for a stream that doesn't appear in logging as started: recorder_rest.log

 

 

 

2014-11-03 13:01:32.0244 [info ][9]: REST PUT /Callback/Heartbeat/1e580c64-52db-11e4-80bc-38eaa7abfd4c
status: OK

 

 

The ID that we have a heartbeat requested for also appears as service from the EPG as seen in recorder_rest.log

 

 

2014-11-03 13:01:47.1654 [info ][10]: REST GET /Callback/Epg/NextServiceToGrab/1e580c64-52db-11e4-80bc-38eaa7abfd4c

 

@@Griffo, no transcoding would be fine for some clients, but my ipad mini (1st gen) can't decode the raw dvb-c streams live. So for an ipad (and probably a lot of other devices) transcoding is needed

 

@@Sven, the errors you get from ffmpeg when transcoding a RTSP stream only appear in the first few seconds right? Isn't that because it dives into a DVB-C stream in the middle and than gets a lot of garbage, there is a certain frame in this stream after which ffmpeg works perfect for me, I'll try to find the name of the frame. 

 

 

 

 

 

 

Looking at some code I've got some questions on whether I understand what is happening, looking at this from livetvservices.cs

 

 

 

public async Task<ChannelMediaInfo> GetChannelStream(string channelOid, CancellationToken cancellationToken)
{
_logger.Info(string.Format("[ArgusTV] Start GetChannelStream Async for ChannelId: {0}", channelOid));
await EnsureConnectionAsync(cancellationToken);

try
{
var channel = Proxies.SchedulerService.GetChannelById(Guid.Parse(channelOid)).Result;
var result = Proxies.ControlService.TuneLiveStream(channel, null).Result;

LiveStream liveStream = result.LiveStream;

if (result.LiveStreamResult == LiveStreamResult.Succeeded)
{
_liveTvTimer.Enabled = true;

return new ChannelMediaInfo
{
Id = channelOid,
Path = liveStream.RtspUrl,
Protocol = MediaProtocol.Rtsp,
//Path = liveStream.TimeshiftFile
};
}

}
catch (Exception ex)
{
_logger.Error(string.Format("[ArgusTV] GetChannelStream async for ChannelId: {0} with exception: {1}", channelOid ,ex.Message));
}

throw new ResourceNotFoundException(string.Format("Could not stream channel {0}", channelOid));
}

 

Specifically:

 

 

 

{
Id = channelOid,
Path = liveStream.RtspUrl,
Protocol = MediaProtocol.Rtsp,
//Path = liveStream.TimeshiftFile
};

 

The channelOid doesn't relate back to the rest-api related to /TuneLiveStream. /TuneLiveStream gives back for example:

 

 

{
"LiveStreamResult":0,
"LiveStream":
{
"Channel":
{
"ChannelId":"2276c60d-703c-409d-a094-3c66247e23c9",
"Id":0,
"GuideChannelId":"3295acfb-4903-4248-b2ec-24efe0b73f1f",
"ChannelType":0,
"DisplayName":"text",
"LogicalChannelNumber":0,
"VisibleInGuide":false,
"DefaultPreRecordSeconds":0,
"DefaultPostRecordSeconds":0,
"BroadcastStart":"text",
"BroadcastStop":"text",
"Sequence":0,
"Version":0
},
"RecorderTunerId":"333fe7cd-32c6-47c4-a25a-60ea754868bb",
"CardId":"text",
"RtspUrl":"text",
"TimeshiftFile":"text",
"StreamStartedTime":"\/Date(1297293089984+0200)\/",
"StreamLastAliveTimeUtc":"\/Date(1297293089984+0200)\/"
}
}

 

 

My guess would be that the keep alive event should sent : RecorderTunerId   as the Id for the stream, and not the Channel ID that we saw before. 

Is my understanding correct?

Edited by Rudig
Link to comment
Share on other sites

Griffo thanks again for these logs.

 

Couple of strange things appear, stream is started and within a second its also stopped: 

 

 

from recorder.log

 

Heartbeat is sent for a stream that doesn't appear in logging as started: recorder_rest.log

 

 

 

The ID that we have a heartbeat requested for also appears as service from the EPG as seen in recorder_rest.log

 

 

@@Griffo, no transcoding would be fine for some clients, but my ipad mini (1st gen) can't decode the raw dvb-c streams live. So for an ipad (and probably a lot of other devices) transcoding is needed

 

@@Sven, the errors you get from ffmpeg when transcoding a RTSP stream only appear in the first few seconds right? Isn't that because it dives into a DVB-C stream in the middle and than gets a lot of garbage, there is a certain frame in this stream after which ffmpeg works perfect for me, I'll try to find the name of the frame. 

 

 

 

 

 

 

Looking at some code I've got some questions on whether I understand what is happening, looking at this from livetvservices.cs

 

 

Specifically:

 

 

The channelOid doesn't relate back to the rest-api related to /TuneLiveStream. /TuneLiveStream gives back for example:

 

 

 

My guess would be that the keep alive event should sent : RecorderTunerId   as the Id for the stream, and not the Channel ID that we saw before. 

Is my understanding correct?

 

That's not the latest code I am testing with. :)

I have some other code in my fork and also local... :)

Link to comment
Share on other sites

Voila latest source is online in my fork....

When we have an error with ffmpeg the stream is closed directly...

Link to comment
Share on other sites

I notice that Argus creates 3 files - the .tsbuffer, a .ts1.ts and a .ts2.ts. 

The .tsbuffer is only 1KB in size. If I point FFMPEG at it, it errors out. If I point it at a .ts1.ts file it converts fine. Maybe we need to use RTSP?

 

Or insert something like tsreader to read the stream properly? I looked at the MP and XBMC plugins for argus, and both projects use MP's tsreader to open the stream. 

Edited by Griffo
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...