Am Freitag, den 05.02.2010, 11:28 -0200 schrieb Mauro Carvalho Chehab: > Andreas Oberritter wrote: > > Hello Andy, > > > > Andy Walls wrote: > >> After investigation, my recommendation for fixing the problem is to > >> revert the patch that is causing the problem. > > Well, the patch were already added on an upstream kernel, so just reverting it > will cause regressions. > > If it is just aletv-dvb that broke, it seems better to fix it than to cause > even more troubles by reverting two new ioctls. > > >> The reason for this is not that fixing the patch is impossible. > > Why? Where exactly the breakage happened?
Mauro, alevt-dvb is the only application that is broken by that kernel patch in question. mtt works, but it is part of a suite of programs, it's not teletext only. So the architexture behind is much more complicated than alevt-dvb itself ever was. Conclusion: fix the application alevt-dvb is the shortest way to solve the problem. CS > >> INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in > >> conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the > >> demux0 device into multiple dynamically created anonymous dvr0 devices, > >> and that is the wrong thing to do. > > > > why exactly do you think this is wrong? > > > >> I understand the need for sending a single PID TS out to an open demux0 > >> instance as described in this email: > >> > >> http://www.mail-archive.com/linux-...@linuxtv.org/msg29814.html > >> > >> even though it seems like a slight abuse of the demux0 device. > > > > How so? It's all about reading demultiplexed packets, which is exactly > > what a demux is good for. There is btw. no other way for multiple > > readers to receive TS packets without implementing a second demux > > layer in a userspace daemon, which must then be used by all readers. > > This would needlessly create quite some overhead on high bandwidth > > services. > >> But sending multiple PIDs out in a TS to the open demux0 device instance > >> is just an awkward way to essentially dynamically create a dvrN device > >> associated with filter(s) set on an open demux0 instance. > > > > Actually it makes dvrN obsolete, but it must of course be kept for > > backwards compatibility. > > > >> It would be better, in my opinion, to figure out a way to properly > >> create and/or associate a dvrN device node with a collection of demuxN > >> filters. > > > > Would this involve running mknod for every recording you start? > > > >> Maybe just allow creation of a logical demux1 device and dvr1 device and > >> the use the DVB API calls as is on the new logical devices. > > > > A demux device (and dvr respectively) represents a transport stream > > input. Hardware with multiple transport stream inputs (read: embedded > > set top boxes) already has multiple demux and dvr devices. > > > Andreas arguments makes sense to me. > > > >> I'm not a DVB apps programmer, so I don't know all the userspace needs > >> nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID > >> ioctl()s. > > > > The need for such an interface was already pointed out and discussed > > back in 2006: > > http://www.linuxtv.org/pipermail/linux-dvb/2006-April/009269.html > > > > As Honza noted, these ioctls are used by enigma2 and, in general, by > > software running on Dream Multimedia set top boxes. I'm sure, other > > projects are going to adopt this interface sooner or later. It is > > still quite new after all. > > > It seems too late for me to revert it. So, we need to figure out a way > to workaround it or to fix the applications that got broken by this change. > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
