https sources (like servusTV) stop streaming

[sedland]

Setup

_Package Name: Tvheadend
_Package Version: v4.3.20191128~221c29b-20

_NAS Model: synology_apollolake_620slim
_NAS Architecture:x86_64
_DSM version: 6.2.2 upd4

Actual behavior

ServusTV shows the first picture and freeze.

Steps to reproduce

1. Configure
https://rbmn-live.akamaized.net/hls/live/2002830/geoSTVDEweb/master_1628.m3u8
as Mux, set int Interface (eth0) and use A/V Lib
2.
Start streaming
3.
compare log.

Package log

Logs:

2020-05-11 22:30:52.367 libav: AVFormatContext: Skip ('#EXT-X-ALLOW-CACHE:NO')
2020-05-11 22:30:52.367 libav: AVFormatContext: Skip ('#EXT-X-VERSION:3')
2020-05-11 22:30:52.367 libav: AVFormatContext: Skip ('#EXT-X-DISCONTINUITY-SEQUENCE:1')
2020-05-11 22:30:52.367 libav: AVFormatContext: Opening 'https://rbmn-live.akamaized.net/hls/live/2002830/geoSTVDEweb/20200305T090925/master_1628/00324/master_1628_00178.ts' for reading
2020-05-11 22:30:52.460 libav: AVFormatContext: Opening 'https://rbmn-live.akamaized.net/hls/live/2002830/geoSTVDEweb/20200305T090925/master_1628/00324/master_1628_00179.ts' for reading
2020-05-11 22:30:52.738 libav: https: Opening 'https://rbmn-live.akamaized.net/hls/live/2002830/geoSTVDEweb/20200305T090925/master_1628/00324/master_1628_00180.ts' for reading
2020-05-11 22:30:56.264 webui: Stop streaming /stream/mux/3c74fb45d42d4c2969656145e0da0409?ticket=10f1cfa9afc8c424907854617b8ef15643e6b402, timeout waiting for packets
2020-05-11 22:30:56.264 subscription: 004C: "HTTP" unsubscribing, hostname="192.168.3.122", client="VLC/3.0.10 LibVLC/3.0.10"

[th0ma7]

Hi @sedland
This issue looks really specific to ffmpeg in conjunction with ServusTV service.

Are you able to reproduce the issue on another platform (e.g. another linux for instance), or success?

Have you reached out to ffmpeg support? (ref Contact section at : https://trac.ffmpeg.org/wiki/Using%20libav*)

Also perhaps related:

• https://video.stackexchange.com/questions/22202/ffmpeg-mpts-detection-of-scrambled-streams

[sedland]

Are you able to reproduce the issue on another platform (e.g. another linux for instance), or success?

My old QNAP has no issues TVH 4.3.1792.

I had tested
https://hub.docker.com/u/wiserain
wiserain/tvheadend:latest-4.3-1857
without issues. (But here I have the issue #3977)

Have you reached out to ffmpeg support? No
But I'll start additional investigation.

[th0ma7]

I'll do a some investigations as well on my side.
I noticed a few other compile options being used by wiserain for tvheadend:

• https://hub.docker.com/r/wiserain/tvhbase/dockerfile

I'll check what they are for exactly and confirm if they shouldn't be included in synoCommunity build.

Still, at first glance, this looks to me more like a software bug than a packaging issue. But lets see what our investigations finds out.

[th0ma7]

Can you give it a try at installing my new packages in my repository here:

• https://github.com/th0ma7/synology/tree/master/packages

I have experimental ffmpeg (-30) and tvheadend (-20) for apollolake arch available. I made a few changes in order to further align with wiserain and was also able to link with VAAPI. Not that this will necessarily solve this issue but worth having a shot.

[sedland]

Not that this will necessarily solve this issue but worth having a shot.
Correct, here are the logs. I see just te first picture and the screen freezes

2020-05-15 22:33:50.942 subscription: 0001: "192.168.3.232 [ | Kodi Media Center ]" unsubscribing from "Das Erste", hostname="192.168.3.232", username="192.168.3.232", client="Kodi Media Center"
2020-05-15 22:33:50.944 mpegts: ServusTV.m3u8 - (13) Servus TV in ServusTV. - tuning on IPTV #1
2020-05-15 22:33:50.944 subscription: 0002: "192.168.3.232 [ | Kodi Media Center ]" subscribing on channel "Servus TV", weight: 100, adapter: "IPTV #1", network: "ServusTV.", mux: "ServusTV.m3u8 - (13) Servus TV", provider: "FFmpeg", service: "Service01", profile="htsp", hostname="192.168.3.232", username="192.168.3.232", client="Kodi Media Center"
2020-05-15 22:33:51.062 libav: AVFormatContext: Skip ('#EXT-X-ALLOW-CACHE:NO')
2020-05-15 22:33:51.062 libav: AVFormatContext: Skip ('#EXT-X-VERSION:3')
2020-05-15 22:33:51.062 libav: AVFormatContext: Skip ('#EXT-X-DISCONTINUITY-SEQUENCE:1')
2020-05-15 22:33:51.062 libav: AVFormatContext: Opening 'https://rbmn-live.akamaized.net/hls/live/2002830/geoSTVDEweb/20200305T090925/master_1628/00343/master_1628_00807.ts' for reading
2020-05-15 22:33:51.203 libav: AVFormatContext: Opening 'https://rbmn-live.akamaized.net/hls/live/2002830/geoSTVDEweb/20200305T090925/master_1628/00343/master_1628_00808.ts' for reading
2020-05-15 22:33:51.341 libav: AVFormatContext: Application provided invalid, non monotonically increasing dts to muxer in stream 1: 3163347704 >= 3163347704
2020-05-15 22:33:51.341 iptv: libav: Error muxing packet: Invalid argument
2020-05-15 22:34:01.153 iptv: m3u parse: 0 new mux(es) in network 'MagentaTV' (total 35)
2020-05-15 22:34:14.751 subscription: 0002: "192.168.3.232 [ | Kodi Media Center ]" unsubscribing from "Servus TV", hostname="192.168.3.232", username="192.168.3.232", client="Kodi Media Center"
2020-05-15 22:34:14.752 tvhpoll: epoll del failed [Bad file descriptor]

[th0ma7]

@sedland I've updated again the tvheadend package, aligning a few reamaining details with wiserain's implementation. Give it a shot and let me knwo if it works out.

BTW, I've found multiple entries related to your problem online. This doesn't look like an easy to solve issue which may be application code or dependency versions related.

[th0ma7]

Found two related issues on tvheadend:

• https://tvheadend.org/boards/4/topics/32961
• https://tvheadend.org/issues/4600

[sedland]

Hi - So summary of the investigation.
After installtion of ffmpeg_x64-6.1_4.2.2-30.spk issue #3977 is back.
I did a reinstall with version v4.3.20191128~221c29b-20 , and ffmpeg_x64-6.1_4.2.2-29.spk
Except ServusTV - no issues. In parallel I'll check the ServusTV link. May be here are some changes to avoid software besides Chrome and FireFox.

[th0ma7]

Hi @sedland
Can you test lastest apollolake package I've made available on my local github repo?
https://github.com/th0ma7/synology/tree/master/packages

• ffmpeg_apollolake-6.1_4.2.3-31.spk
• tvheadend_apollolake-6.1_4.3.20200521~e59b92e-22.spk

[th0ma7]

@hgy59 quick question for you, shouldn't openssl be fixed as well such as curl part of #4066 so it points to default system wide CA certificates which could explain the issue here?

It currently point into the target directory:

root@th0ma7-nas:~# /var/packages/tvheadend/target/bin/openssl version -d
OPENSSLDIR: "/var/packages/tvheadend/target"

Or openssl simply being too old as dating from December 2017... (1.0.2n)

[th0ma7]

Hi @sedland
I have 3x solution options for you to test:

1. Can you create a symbolic link in tvheadend to point to the system-wide default CA certificates?

$ ssh admin@my-nas
admin@my-nas's password:
$ sudo ln -s /etc/ssl/certs /var/packages/tvheadend/target/certs

2. Try out the new package (tvheadend + ffmpeg) I made available for you that include an updated openssl at:

• https://github.com/th0ma7/synology/tree/master/packages/sedland

3. Try out the experimental ffmpeg version 4.3.1 + tvheadend at:

• https://github.com/th0ma7/synology/tree/master/packages/ffmpeg-4.3

My hope is that option no. 1 fixes things and would be real easy to implement.

Lastly, if none of the 3x options works out, could you provide me with a reproducible example would be really helpful for me to do debugging from my side directly?

[sedland]

Hello @hgy59 <https://github.com/hgy59> Will start next week. Do you have a way for backup/recover of the current installation. I do not have a test system. .... Thanks and kind regards

…

------ Originalnachricht ------ Von: "Vincent Fortier" <[email protected]> An: "SynoCommunity/spksrc" <[email protected]> Cc: "sedland" <[email protected]>; "Mention" <[email protected]> Gesendet: 07.08.2020 13:50:24 Betreff: Re: [SynoCommunity/spksrc] https sources (like servusTV) stop streaming (#3988)

Hi @sedland <https://github.com/sedland> I have 3x solution options for you to test: Can you create a symbolic link in tvheadend to point to the system-wide default CA certificates? $ ssh ***@***.*** ***@***.***'s password: $ sudo ln -s /etc/ssl/certs /var/packages/tvheadend/target/certs Try out the new package (tvheadend + ffmpeg) I made available for you that include an updated openssl at: https://github.com/th0ma7/synology/tree/master/packages/sedland Try out the experimental ffmpeg version 4.3.1 + tvheadend at: https://github.com/th0ma7/synology/tree/master/packages/ffmpeg-4.3 My hope is that option no. 1 fixes things and would be real easy to implement. Lastly, if none of the 3x options works out, could you provide me with a reproducible example would be really helpful for me to do debugging from my side directly? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3988 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACM4T32SQNQAXFGQ7HVAKHTR7PTABANCNFSM4M6HORJA>.

[th0ma7]

Ok, redocumenting to provide a bit more clarity...

Run the following to create a backup into a local directory of yours (e.g. mine is /volume1/backup/tvheadend):

sudo tar -C /var/packages/tvheadend/target -jcvf - \
    --exclude='.lock' \
    --exclude='tvheadend.pid' \
    cache var \
    > /volume1/backup/tvheadend/tvheadend-backup-`date +%Y%m%d-%H%M`.tar.bz2

Then upgrade/downgrade tvheadend package as needed. Once done first stop tvheadend:

$ sudo synoservice --stop pkgctl-tvheadend

Restore the backup (filename will vary based on date & time it was performed):

$ sudo tar -C /var/packages/tvheadend/target -jxvf /volume1/backup/tvheadend/tvheadend-backup-20200809-0853.tar.bz2

Restart the tvheadend service:

$ sudo synoservice --start pkgctl-tvheadend

[ymartin59]

Notice: if your records have been stored in /var/packages/tvheadend/ you may face troubles with package upgrade and/or DSM upgrade which may take too long because of too many of large files to backup/restore.
It is recommended to move your records into a DSM volume folder: /volumeX/records for instance.

[sedland]

Hello All - Sorry - I'll stop at this point. Backup /Restore does not work. TVheadend had fully crashed once more. I'll go back to QNAP. Many thanks for your kindly help.