Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Random Live-TV freezes #46

Open
lacunoc opened this issue Dec 29, 2015 · 11 comments
Open

Random Live-TV freezes #46

lacunoc opened this issue Dec 29, 2015 · 11 comments

Comments

@lacunoc
Copy link

lacunoc commented Dec 29, 2015

Hey there,

dunno if it's the right repo or if it's a vdr-plugin-vnsiserver issue, but since the update to openelec 6.0 I got random freezes of Live-TV. While the pictures freezes it's still possible to use the menu and to stop the stream. When I started it again it will freeze again after a few seconds. After a reboot of openelec it will work for several hours +/-

I think there are users with a similar problem: http://openelec.tv/forum/87-vdr-addon/79303-need-help-live-tv-freeze-after-a-short-play?limitstart=0

I have the feeling that it will work longer when I disable timeshift function but I'm not sure.

Log-Entries of kodi when the problem appears:
00:00:02 201398.875000 T:1585157184 ERROR: AddOnLog: VDR VNSI Client: ReadResult - request timed out after 3 seconds
00:00:02 201398.875000 T:1585157184 ERROR: AddOnLog: VDR VNSI Client: GetDriveSpace - Can't get response packed
00:00:05 201401.875000 T:1585157184 ERROR: AddOnLog: VDR VNSI Client: ReadResult - request timed out after 3 seconds
00:00:05 201401.875000 T:1585157184 ERROR: AddOnLog: VDR VNSI Client: GetChannelsCount - Can't get response packed
00:00:08 201404.875000 T:1585157184 ERROR: AddOnLog: VDR VNSI Client: ReadResult - request timed out after 3 seconds
00:00:08 201404.875000 T:1585157184 ERROR: AddOnLog: VDR VNSI Client: GetTimersCount - Can't get response packed
00:00:11 201407.875000 T:1585157184 ERROR: AddOnLog: VDR VNSI Client: ReadResult - request timed out after 3 seconds
00:00:11 201407.875000 T:1585157184 ERROR: AddOnLog: VDR VNSI Client: GetRecordingsCount - Can't get response packed

Log-Entries of VDR server in the regarding timeframe:
Dec 29 00:05:20 hp-g8 vdr: [28230] VNSI: cxSocket::read: eof, connection closed
Dec 29 00:05:25 hp-g8 vdr: [28230] ERROR: cLiveStreamer stream processor thread 28233 won't end (waited 5 seconds) - canceling it...
Dec 29 00:05:25 hp-g8 vdr: [28230] VNSI: LiveStreamer::Close - close
Dec 29 00:05:25 hp-g8 vdr: [28230] VNSI: close video input ...
Dec 29 00:05:25 hp-g8 vdr: [28230] VNSI: call retune ...
Dec 29 00:05:25 hp-g8 vdr: [28230] CAM 1: unassigned
Dec 29 00:05:25 hp-g8 vdr: [28230] VNSI: call retune ...
Dec 29 00:05:25 hp-g8 vdr: [28234] device 1 TS buffer thread ended (pid=61758, tid=28234)
Dec 29 00:05:25 hp-g8 vdr: [28231] buffer stats: 1266180 (24%) used
Dec 29 00:05:25 hp-g8 vdr: [28231] device 1 receiver thread ended (pid=61758, tid=28231)
Dec 29 00:05:40 hp-g8 vdr: [28230] VNSI: close video input ...
Dec 29 00:05:40 hp-g8 vdr: [61770] VNSI: Client with ID 44 seems to be disconnected, removing from client list

Anybody got any idea why this is happening? Do I need to update the vnsi plugin to 1.11.11? I can't compile it on openelec, so how to get it done?

My setup:
Server: VDR 2.2.0 with vnsiserver 1.3.1 @ Debian 7.9
Client: 2x Openelec 6.0 @ Raspberry Pi1/Pi2 with vnsi plugin 1.10.10

When u need further information, feel free to give me advise.

Thanks in advance!

@FernetMenta
Copy link
Contributor

what did you set priority to? addon settings

@lacunoc
Copy link
Author

lacunoc commented Dec 29, 2015

Thanks for your quick answer!

I thought I changed it to the highest value (99? and default was... -1?) on my Main Pi so a upcoming recording is not stopping the stream.

These are my different settings.xml's of the two Pis:

Main Pi:
<settings>
<setting id="autochannelgroups" value="false" />
<setting id="convertchar" value="true" />
<setting id="handlemessages" value="true" />
<setting id="host" value="192.168.1.2" />
<setting id="iconpath" value="" />
<setting id="port" value="34890" />
<setting id="priority" value="22" />
<setting id="timeout" value="3" />
<setting id="timeshift" value="0" />
<setting id="wol_mac" value="" />
</settings>

Other one:
<settings>
<setting id="autochannelgroups" value="false" />
<setting id="convertchar" value="true" />
<setting id="handlemessages" value="true" />
<setting id="host" value="192.168.1.2" />
<setting id="iconpath" value="" />
<setting id="port" value="34890" />
<setting id="priority" value="1" />
<setting id="timeout" value="3" />
<setting id="timeshift" value="1" />
<setting id="wol_mac" value="" />
</settings>

I hope this helps.

@FernetMenta
Copy link
Contributor

are you saying that the value of priority does not make any difference?

@lacunoc
Copy link
Author

lacunoc commented Dec 29, 2015

It makes a difference, the stream is not stopping when a recording should start. Thats why I changed it on my Main Pi to the highest values, which I thought was 99 in the GUI. Are there different ones I see in the GUI? Can't check up right now, cause I'm not at home.

@FernetMenta
Copy link
Contributor

also make sure that yo have set AvoidEPGScan to 1 (setup.conf)

@FernetMenta
Copy link
Contributor

It makes a difference, the stream is not stopping when a recording should start.

the question was if it makes a difference in regard to the issue

@lacunoc
Copy link
Author

lacunoc commented Dec 29, 2015

the question was if it makes a difference in regard to the issue

I would say no, no difference regarding this issue.

The only option which is set actually in my setup.conf is:
vnsiserver.Timeshift = 2

so I should add:
vnsiserver.AvoidEPGScan = 1

right?

@lacunoc
Copy link
Author

lacunoc commented Dec 29, 2015

While I'm reading the possible config values for vnsiserver in setup.conf, I've got a question:

As long as the serverside Timeshift value is "2", a client is using timeshift anyway, right? Because my recording directory is a NFS-Share and I didn't redeclare the vnsiserver.TimeshiftBufferDir to use a local directory (or vnsiserver.TimeshiftBufferFileSize, vnsiserver.TimeshiftBufferSize)

Could this be a problem? And which BufferFileSize and BufferSize should be used?

/edit:
And I saw your commit 65b0e9d (make avoid EPG scan while streaming default) which should be included in my yesterday new compiled vdr-plugin-vnsiserver

@FernetMenta
Copy link
Contributor

Easiest way to change parameters is to use VDR UI provided by vnsi.

As long as the serverside Timeshift value is "2", a client is using timeshift anyway, right?

if this is the case, there is a bug

I won't put the timeshift file on a NFS share but this does not cause this issue. The problem is most likely that EPG scan interrupts playback. What other vdr plugins do you have loaded? I think that one of them pretends to be a full featured device having a decoder.

And I saw your commit 65b0e9d (make avoid EPG scan while streaming default) which should be included in my yesterday new compiled vdr-plugin-vnsiserver

This only has an influence on new installations.

@lacunoc
Copy link
Author

lacunoc commented Jan 4, 2016

As long as the serverside Timeshift value is "2", a client is using timeshift anyway, right?

if this is the case, there is a bug

I tested it and I think it's a bug. When I disabled timeshift on a client it's using timeshift anyway, when the serverside timeshift is enabled.

And I saw your commit 65b0e9d (make avoid EPG scan while streaming default) which should be included in my yesterday new compiled vdr-plugin-vnsiserver

This only has an influence on new installations.

AvoidEPGScan was already enabled as I saw it in VDR UI via Kodi. So that was not problem.
But I think I solved my problem by changing the timeshift setting from "File" (NFS-Share) to "RAM" (Serverside).

No more complaints so far.

Thanks for your help and time!

@FernetMenta
Copy link
Contributor

thanks for feedback. I will look into the timeshift enabled bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants