https://bugs.kde.org/show_bug.cgi?id=364298
--- Comment #24 from Mauro Carvalho Chehab <mchehab+...@kernel.org> --- (In reply to lev.cohan from comment #22) > I did build v4l-utils from the commits 11c6e2c earlier and 9b8e58f now and > with neither version I manage to make a complete scan with "dvbv5-scan -p", > it always segfaults or stalls. Using the verbose command line parameter it > crashes even faster. Ok. It would be good later send me what's happening there, for me to fix the bug at the tool as well. I'm planning switch the Kaffeine scan algorithm to use the one at v4l-utils in some future, in order to be able to maintain just one code. So, it will benefit Kaffeine if we can make it more reliable. > There are also a lot of error messages of "channels not > found on PMT" shown and the channels are not stored with their "names" but > in the pattern "FREQUENCY#SERVICE_ID", which is somewhat cumbersome. That's because it will use the "other SDT" tables too. For your cable TV provider, it seems that it needs to use NIT + other NIT + SDT tables and ignore other SDT tables. I need to change the logic at libdvbv5 to append new SDT entries instead of replace the tables. > In comparison to "dvbv5-scan -p" the old "scan -n" from > https://linuxtv.org/hg/dvb-apps > manages to do this flawlessly, even the different "Network Names" > (probably the different Network-IDs) are identified. I attached the > resulting file "dvbv3_channels.conf" with the 533 services found. Ok. Yeah, those other Network IDs come from the other NIT tables. The patch at https://bugs.kde.org/attachment.cgi?id=99591 should force Kaffeine to handle such tables. Please test and report if it is able to find all channels. > By the way, with my TV set I have to enter the Network-ID (here 43016) for > the channels scan. Could this enhance or speed up the scanning process if > the user could define that and it would be incorporated in the scanning > process? Yes. The normal NIT table has ID = 0x40 and it is just one table, and, on your case, it lists 12 transponders. The "other NIT" is actually a series of different extensions, all identified with Table ID 0x41, bu with different extension IDs. Each extension provides a set of transponder frequencies. The total amount of transponders there is 83 transponders. If it gets just one of those tables, the number of transponders will be less than 83, speeding up the tuning. So, for a final patch, it is likely interesting to add some options to avoid the user the need of scanning transponders that will never be available for him, e. g. allowing them to completely disable other NIT or to filter just one (or a few?) other NITs. Doing an easy to use GUI interface for it could be tricky, though. -- You are receiving this mail because: You are watching all bug changes.
