Tvheadend

Can you try an unstable build, I fixed a few scanning bugs but haven't had
time to backport and do a new 3.4 build.

Adam
On May 19, 2013 10:06 AM, wrote:

Issue #1739 has been reported by bas t.
------------------------------
Bug #1739: TVH 3.4 not auto-detecting muxes

- Author: bas t
- Status: New
- Priority: Normal
- Assignee:
- Category:
- Target version:
- Found in version: 3.4~wheezy
- Affected Versions:

In #1472 I got at least 25 out of 32
muxes.

Now I get none.

3.2.34~gfaee94b is still good, so nothing has changed with my provider.
------------------------------

You have received this notification because you have either subscribed to
it, or are involved in it.
To change your notification preferences, please click here:
https://tvheadend.org/my/account

Unstable detected all muxes, but like in #1472 still no network names for muxes that are only in nit other.
Some of the muxes are in the main table too, they will get proper network names, the others don't.

I noticed you have ziggo, i see a lot of ziggo complaints on dutch forums like tweakers.net with tvh3.4

tvh3.4 detects ziggo muxes (with wrong qam) with services and totally wrong frequencies, maybe this helps you:

https://tvheadend.org/issues/1708#note-5

No, it does not help me. The only mux-detecting issue I've got left is that release/3.4 (as opposed to release/3.2) does not give all the muxes and transports proper network names. Should name them Ziggo, of course, but only does so when the mux is also in the main nit (1000).

Is it possible to backport the scanning fixes to 3.4?

OpenELEC is shipping the stable version and some users can't use tvh with OE right now...

https://github.com/OpenELEC/OpenELEC.tv/issues/2396