IRCloggy #hts 2013-10-19

Logs Search ←Prev date Next date→ Channels Documentation

Provider of IRC logs since 2005.
WARNING: As Freenode became unjoinable and lost all warnings in topics, we cannot log channels on Freenode anymore.

2013-10-19

← zombor left00:04
→ IvanG1 joined00:12
← IvanG left00:14
→ mablae_ joined00:20
← IvanG1 left00:22
← john3voltas left00:27
← lja left00:30
→ lja joined00:30
→ _julian joined00:38
← _julian_ left00:38
← mablae_ left00:56
→ mablae_ joined00:58
← lja left00:59
→ lja joined00:59
← mablae_ left01:08
→ bowman^2 joined01:43
← bowman left01:45
← Rudde left01:56
← lja left01:56
→ lja joined01:57
← lja left02:25
→ lja joined02:25
← lja left03:23
→ lja joined03:23
gustaf_offline → supergustaf03:41
← lja left03:52
→ lja joined03:52
→ newpipe joined04:25
← lja left04:49
→ lja joined04:50
→ zombor joined04:52
← zombor left04:54
→ zombor joined04:55
← zombor left04:55
→ zombor joined04:55
← zombor left05:10
← lja left05:18
→ lja joined05:18
→ NisseDILLIGAF joined06:06
← lja left06:16
→ lja joined06:16
← lja left06:45
→ lja joined06:45
→ _Dweller joined06:49
_Dweller tried hacking the dvb branch to make it read from /dev/video0 instead of a flat ts file (not much of a hack, killed of the length detect & reset code).. now get pages of errors about how his stream has 'continuity counter errors' ;p06:50
_Dweller killed off/killed of06:50
suspect I'll need to merge my read buffering code into the read loop.. almost certain it's not pulling the data off /dev/video0 fast enough so it's losing packets07:02
well .. some good news.. If I use the existing ts file support to serve a recording I made, there are no continuity errors, so the data from the device is compliant.. sadly it does glitch a little on playback (file doesnt if played direct in vlc) .. mebbe it's trying to remux it or something07:12
seems recording type affects streaming too.. setting mkv results in glitches, setting 'as-is' means single frame is sent, but no motion, setting mpeg-ts means working video, no audio..07:17
← lja left07:42
→ lja joined07:42
← lja left08:11
→ lja joined08:11
supergustaf → gustaf_offline08:12
linuxstb_ _Dweller: What do you mean by serving a recording? Are you sure tvh parses the stream when doing that?08:16
adamsutton TVH doesn't parse anything when serving recordings, they're just treated as files, the rest is up to the client08:32
← lja left08:34
linuxstb_ → linuxstb08:38
→ IvanG joined08:58
_Dweller I mean serving a .ts file I recorded using my prog, using --tsfile output.ts09:02
I think when using tsfile as a source, that it's still doing remuxing for the stream (else the container type in the recording settings wouldn't affect the output) ..09:03
not sure why it doesnt like my .ts .. I can upload it if you want to try seeing how you get on09:04
→ Rudde joined09:06
→ DereC joined09:07
_Dweller adamsutton: ts url https://i.cloudup.com/7Zy44ntm3x.ts (~ 50mb) .. run with --tsfile & see if you get stutter free playback in vlc with MKV mux, or audio with TS mux, or anything with 'as-is' mux09:18
_Dweller goes back to decorating.. (yay for diy!.. not)09:21
linuxstb _Dweller: I have a little program that checks a TS for CC errors - your file is fine.09:32
_Dweller: Also, the "tstools" package is useful. Try "tsinfo" on your file for example to see the PAT/PMT contents.09:35
_Dweller aye.. I figure my file is ok.. my recording prog didn't lose any packets when saving it.. think there may be an issue with the demux / remux path inside tvheadend (I'm on the dvb-rewrite branch) .. that's causing it not to be streamed correctly.. it's not a cpu limit issue.. I have plenty of overhead left09:48
once/if I can get tvheadend to stream the .ts file ok via the --tsfile plugin, I'll know its worth the effort to add a new threaded device reader to pull packets from the device & buffer them, while a 2nd thread feeds them into tvheadend.. the single 'read and feed' loop at the mo in tsfile doesnt work for a live device with few internal buffers..09:50
with the /dev/video0 for the hd pvr, it's critical to keep reading from the device node, as otherwise the stream breaks.. I had to move to a 2 thread approach in my code to avoid that (as even writing to disk/sockets introduced enough variable latency to the reads that the stream could get damaged)09:52
← DereC left09:57
→ xhaggi joined09:59
adamsuttoncloud _Dweller: I've not checked tsfile for quite a while. Probably broken it. It adds additional complexity not needed when using a real data source.10:17
→ john3voltas joined10:18
← xhaggi left10:29
← seld left10:32
→ seld joined10:35
_Dweller adamsuttoncloud: whats a good input to look at that takes in ts formatted data that you think should work at the mo ?10:36
← sirdancealot left10:39
_Dweller looking at the iptv one, its not really any different.. take data from socket, and pass to mpegts_input_recv_packets, storing the pos returned..10:39
adamsutton _Dweller: the issue with tsfile is that its having to rate limit the data, which adds some additional (though should be minor) load to TVH and potential to simply get it wrong10:42
_Dweller ah.. but then.. reading from the real device will give packet delivery in realtime =)10:43
adamsutton I might have broken the PCR extraction or something, though can't think what I've done recently that would have done that. But I've not checked10:43
_Dweller: exactly, much easier10:43
_Dweller the lack of audio in the ts output mux wouldn't be a rate limit issue tho10:43
the glitches in the mkv might be..10:43
adamsutton indeed, that sounds like a different problem10:44
_Dweller the total failure of as-is.. who knows =)10:44
adamsutton you said the device has very small buffers, do you know exactly how small?10:45
people certainly do use S2 muxes on pi (multiple) on TVH without issue, except when USB is miisbehaving ofc10:46
_Dweller I don't.. I do know that once you start reading from /dev/video0 you really really have to keep pulling the data off there fast, else you'll have glitches in your stream10:46
it's the most common reported issue with the usb hd pvr device, (beyond the need for a hard power reset occasionally, and bad psu's) .. that doing cat /dev/video0 > output.ts works.. but it's pretty chancey as to if you'll get a clean stream10:47
adamsutton well, I don't see that's any diff to any other device, unless it really does have insanely small buffers10:47
_Dweller since I moved to a double threaded approach.. one thread to pull data off the device put it in a buffer, and a 2nd thread to take from the buffer and actually do anything.. I've not had a single glitched recording10:48
adamsutton TVH should be pretty efficient, though I agree that you could add a message Q (don't think there is one by default) in the pipeline10:48
but to be honest if the buffers were that insanely small, without properly sorting out threading priorities you'll still get stuck10:48
_Dweller it's that buffer I was describing yesterday that I've seen growing to 48mb10:48
adamsutton well, that's just an inefficiency in the code or upstream sending/writing10:49
which is not the issue here10:49
_Dweller but thats because my output thread is writing to sockets, and to smb mounted filesystems, which take variable amounts of time to write to10:49
adamsutton 48M is a VERY long time on a ~10-20Mb stream10:49
_Dweller (the smb writes can really slow down when things get busy)10:49
device is set to record around 13mbps10:49
adamsutton well that's not an issue for TVH, writing to clients (or files) is obviously not handled in the main reception thread10:50
but basic stream processing is, though I need to double check there aren't any message Q's in the pipeline (but pretty sure there aren't)10:50
_Dweller how much work does the mpegts_input_recv_packets method do? is it just a buffer handoff, or does it parse the data ?10:50
adamsutton parsing is does in that thread10:51
I think10:51
_Dweller kk.. so I might gain an advantage to moving my data reads off to their own thread then10:51
atm they are being done by the same thread invoking the recv method10:51
adamsutton I would very much doubt it, unless that device really does have insanely small buffers10:51
_Dweller I'm under the impression it does.. I have nothing to offer to back that up beyond experience tho10:52
adamsutton though I'm certainly not against it in principle, it would be my normal approach tbh10:52
but I've never seen any need for it in any use of TVH, including very high bitrate streams on low power devices like the pi10:53
but then they might have more sane buffers internally10:53
_Dweller yeah.. if you read around other pvr projects using the hd pvr, there's usually a long tale of people gradually figuring out how to get it stable10:54
brb after food =)10:54
adamsutton _Dweller: you should actually see errors if TVH is genuinely not reading quick enough, assuming the driver returns the correct error values10:55
→ ant_thomas joined11:30
john3voltas Hi there folks. i know this is not the most appropriate channel to ask this but #linuxtv is not as active as hts and i am using tvheadend. i'm trying a dvb-t usb adapter on tvheadend (arch linux). it's a rtl2832u+r820t dongle.11:38
tvheadend finds the dongle and it can even show me epg but image quality is horrible. yet, if i try the same dongle on windows 7 image is quite acceptable.11:38
anybody has an idea on what could be happening?11:38
gustaf_offline → supergustaf11:49
← ant_thomas left11:49
→ ant_thomas joined12:19
adamsutton _Dweller: had a quick look at your ts file, plays fine with TVH --tsfile, some lip sync issues, but I'm getting that with VLC as well. I'm admittedly on an i7 laptop, but CPU loading is 2-3%.12:23
← cheasee left12:28
bowman^2 → bowman12:59
supergustaf → gustaf_offline13:06
→ xhaggi joined13:22
← xhaggi left13:22
_Dweller adamsutton: hmm.. that def points at the pi being the culprit.. I'm using VLC as a client on win7 (i5@4ghz) .. the pi cpu isn't maxed out when streaming it tho..13:24
how'd you get on with the different mux types for playback ? mkv/ts/as-is13:24
adamsuttoncloud _Dweller: I only tried mkv, remuxing in passthru is minimal, so usually if mkv works id expect pass thru to be fine.14:03
→ superdump joined14:24
→ zombor joined14:34
← zombor left14:34
→ zombor joined14:34
amet bow around?14:50
→ zipleen joined14:51
→ beercan joined15:12
beercan Hi, could anyone explain what this means? :/15:13
Oct 19 17:09:54 ubuntu tvheadend[957]: cwc: ch2.nohost.nu:20035: conax card15:13
Oct 19 17:09:54 ubuntu tvheadend[957]: cwc: ch2.nohost.nu:20035: Provider ID #1: 0x000000 00.00.00.00.00.00.00.0015:13
Oct 19 17:09:55 ubuntu tvheadend[957]: cwc: ch2.nohost.nu:20035: Decoderloop: Read error (header): Software caused connection abort15:13
→ DereC joined15:23
← zombor left15:25
beercan Found the error..15:39
bowman amet?15:45
amet bowman: any idea about emm updates on oscam? I have 2 cards 0100:000064 for a friend and I cant get tvh to send any emms to it to refresh entitlemens and activate it15:48
0100:000064/0100:00006A15:49
bowman use oscam dvbapi to gather the emms15:51
if there is any place that has the correct logic for those seca artefacts it would be there15:51
amet I use both, dvbapi and cwc and none send anything.. its worth noting that cards are inactive and need few emms to refresh I suppose15:52
bowman then you'd have to start looking through the oscam source and dvbsnoop them manually15:53
and find whatever filtering flaw is preventing them from getting picked up15:53
assuming you're sure about the config at both ends and that all card details are made available to the client thats trying to forward emms15:54
amet tvh has reported that "emm will be forwarded"15:55
will see what I can find15:56
bowman well that should at least indicate that the server end is allowing them15:56
amet yeah, I see in oscam that AU is allowed for user15:56
← superdump left16:00
← _Dweller left16:01
→ _Dweller joined16:03
→ zombor joined16:12
← zombor left16:12
→ zombor joined16:12
← zombor left16:32
← linuxstb left16:33
DereC amet reader .. AU Provid: ?16:38
→ serafean joined16:40
amet I have tried everything 00006A, 00000016:43
DereC^^16:43
← DereC left16:43
← serafean left16:59
→ zombor joined17:07
→ stv0g joined17:12
stv0g hey :-) how do i can contribute a patch?17:13
ive ported transcoding.c to the newest libavcodec version. there is also a bugreport for this. but im uncertain how to contribute it17:14
patch? oder github pullrequest?17:14
→ cheasee joined17:17
← zipleen left17:20
bowman pr17:23
← zombor left17:23
→ decke joined17:32
→ zipleen joined17:33
→ AndrevS joined17:33
← stv0g left17:39
→ DereC joined17:45
→ linuxstb joined17:55
→ serafean joined18:08
← serafean left18:14
→ serafean_ joined18:14
← DereC left18:16
← decke left18:24
→ felipeal` joined18:28
← felipealmeida left18:30
→ sirdancealot joined18:40
→ Serafean joined19:09
← serafean_ left19:09
← john3voltas left19:10
← zipleen left19:14
→ john3voltas joined19:19
← Serafean left19:23
→ Serafean joined19:24
← Serafean left19:33
→ DereC joined19:47
← highzeth left20:02
→ highzeth joined20:03
gustaf_offline → supergustaf20:04
supergustaf → gustaf_offline20:05
← DereC left20:06
→ superdump joined20:06
← john3voltas left20:08
← NisseDILLIGAF left20:09
← newpipe left20:32
→ DereC joined20:33
→ holli73 joined20:49
holli73 i had to change my 0d05 card to a 0d95 - where can i change the service using now the new caid20:51
→ holl73 joined20:51
← DereC left20:53
← holli73 left20:54
← _Dweller left20:55
← holl73 left20:56
→ holl73 joined20:57
← holl73 left21:01
→ holl73 joined21:07
← superdump left21:11
← AndrevS left21:16
← holl73 left21:28
→ DereC joined22:23
← JackWinter left22:25
→ JackWinter joined22:25
← DereC left22:28
← kendrak24_ left22:46

Logs Search ←Prev date Next date→ Channels Documentation