| Sunday, August 11th, 2013, 00:05 UTC | ||
| [00:05:05] | clever_ is now known as clever | |
| [00:14:29] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [00:30:45] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [00:31:15] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Client Quit) | |
| [00:50:22] | CeilingKitten (CeilingKitten!~CeilingKi@206-248-157-46.dsl.teksavvy.com) has quit (Ping timeout: 240 seconds) | |
| [01:07:56] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Read error: Operation timed out) | |
| [01:24:40] | wagnerrp: | not sure why i would be the person to ask |
| [01:25:15] | wagnerrp: | i've got my work laptop configured to network boot and run a frontend, but i've not used it enough to say it runs linux well |
| [01:27:18] | wagnerrp: | it's also a bit overspecced for a frontend (quad core, 12GB, 2GB K2000M) |
| [01:28:41] | jpabq: | taylorr: what kernel are you running? Ever since I upgraded from Fedora 17 to 19, my hd-pvrs have been a LOT more flaky. I think I figured out what is going on --- with the newer driver, the HD-PVR will not actually /start/ streaming reliably until a READ is seen. With the older driver, the "start streaming" ioctl was enough to get it going. In very limited testing, this http://pastebin.com/7MDgsTA4 seems to fix it for me. |
| [01:52:22] | joki (joki!~joki@p54862364.dip0.t-ipconnect.de) has quit (Read error: Operation timed out) | |
| [01:58:24] | joki (joki!~joki@p54860FA7.dip0.t-ipconnect.de) has joined #mythtv | |
| [02:20:11] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Read error: Operation timed out) | |
| [02:25:15] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [02:35:37] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [02:36:23] | knightr: | wagnerrp, most likely because you were known to have tried it... :) |
| [02:38:36] | knightr: | my main PC is having disk troubles (which supposedly the OS is currently trying to fix) and I have been wanting for a while to but myself a stronger laptop than the small netbook I am currently typing on... |
| [02:39:32] | knightr: | It wouldn't be solely used for MythTV and it would need to have a Winblows partition on it too... |
| [02:44:17] | wagnerrp: | this one is windows only (so far) |
| [02:44:22] | wagnerrp: | i've only used linux for netboot |
| [02:44:39] | knightr: | One of the things I am concerned about is that many laptops nowadays which have Nvidia chipsets (which I would prefer to have) have something called Optimus that could mean trouble under Linux (but it's been a while since I read on it..) |
| [02:44:47] | knightr: | ah, ok... |
| [02:44:59] | knightr: | s/but/buy |
| [02:45:00] | clever: | knightr: is that the dual gpu power saving stuff? |
| [02:45:09] | knightr: | clever, yep... |
| [02:45:18] | wagnerrp: | i don't recall that specific name, but this has something of that sort |
| [02:45:21] | wagnerrp: | flipping between onboard intel and the quadro card as needed |
| [02:45:34] | wagnerrp: | for the internal screen only |
| [02:45:37] | knightr: | IIRC it is Optimus.. |
| [02:45:40] | clever: | knightr: if you ignore all the special stuff, then you just get a bare intel gpu with basic 2d support |
| [02:45:43] | wagnerrp: | the four external ports are only off the nvidia |
| [02:46:00] | clever: | i havent checked, but i suspect that the intel gpu would do fine for mythtv |
| [02:46:09] | clever: | we arent trying to render billions of polygons at 30fps |
| [02:46:23] | knightr: | i\that's what I had been wondering.. |
| [02:47:20] | clever: | just enable the intel driver and ignore the nvidia gpu |
| [02:47:38] | knightr: | (especially with today's CPUs, things like VDPAU are probably not needed... |
| [02:48:09] | clever: | do you happen to know anything about transport stream protocols? |
| [02:48:22] | Moeabm09 (Moeabm09!~moeabm@209.242.163.66) has joined #mythtv | |
| [02:48:36] | knightr: | unfortunately not, maybe Raymond does? |
| [02:48:48] | wagnerrp: | nope |
| [02:49:16] | clever: | ive been able to decode the rtp layer, but i cant see any obvious size for the mpeg2 payload |
| [02:49:16] | wagnerrp: | knightr: yeah, haven't bothered using VDPAU on it yet |
| [02:49:29] | wagnerrp: | ATSC decoding is inconsequential on the CPU |
| [02:49:33] | knightr: | I believe I read rtp support was added this time but I don't know how to use it... |
| [02:49:46] | clever: | wireshark shows 7 packets within this RTP packet |
| [02:50:03] | clever: | but i cant see any indication of the size of those 7 packets, so i cant parse the 2nd one |
| [02:50:23] | clever: | i tried feeding the rtp url to myth, but got http://privatepaste.com/70c0af314c |
| [02:50:27] | clever: | 2013-08–07 19:09:15.243973 N DTVSM(): PMT says program 8208 is encrypted |
| [02:50:49] | clever: | so i'm trying to write a simple program that will open a stream and just say yes/no for encryption, so i can test things in bulk |
| [02:51:32] | clever: | http://en.wikipedia.org/wiki/MPEG_transport_stream#Packet |
| [02:51:51] | clever: | this appears to describe the packets i have, but doesnt explain the lenght of the payload |
| [02:54:08] | knightr: | so essentially you want to write a program that scans them to find which are encrypted or not... |
| [02:54:40] | clever: | yep |
| [02:54:54] | clever: | it would take too long to open mythtv-setup and change the rtp url for all 500 channels |
| [02:55:22] | knightr: | obviously the Myth knows how to parse that info, how it parses it would have to be dug up... |
| [02:55:30] | knightr: | s/the// |
| [02:55:49] | clever: | yeah, thats one option, *opens github* |
| [02:56:50] | knightr: | the message you get is from mythtv/libs/libmythtv/recorders/dtvsignalmonitor.cpp, but the info must be provided from elsewhere, it's just processed these I think... |
| [02:58:14] | clever: | yeah, that is calling IsEncrypted |
| [02:59:40] | clever: | ./mpeg/mpegtables.cpp:bool ProgramMapTable::IsEncrypted(QString sistandard) const |
| [03:01:28] | clever: | hmmm, it appears to be looping over each stream in the PMT and calling IsStreamEncrypted, but how did it parse the pmt in the first place |
| [03:02:00] | knightr: | where is it called from? mythtv/libs/libmythtv/mpeg/mpegstreamdata.cpp ? |
| [03:02:58] | clever: | https://github.com/MythTV/mythtv/blob/master/ . . . ata.cpp#L660 |
| [03:03:09] | knightr: | wagnerrp, Thank you, I'll let you know how it turns out... |
| [03:03:15] | clever: | i'm guessing this is where it creates the PMT object, from the stream |
| [03:04:24] | knightr: | yep, looks like this is where it's coming from... |
| [03:05:40] | clever: | looks like there are also some -v flags i could enable |
| [03:06:06] | knightr: | hmm, that could be useful to have a better idea of what's going on... |
| [03:06:40] | clever: | telephone, internet, and tv, all come into the house over a fiberoptic line |
| [03:07:06] | clever: | the 'modem' will split the telephone into the old copper pair, and everything else into 802.1q (vlan tagged) over ethernet |
| [03:07:40] | clever: | vlan 34 is directly linked to the iptv network and gets bridged into the LAN for multicast streams |
| [03:07:51] | clever: | vlan 35 is the internet link, dhcp gets a public ip, then NAT provides normal internet |
| [03:08:40] | clever: | if any system in the house joins the right multicast group, the router at the far end of the fiber will begin sending a copy of all the multicast packets |
| [03:09:04] | clever: | so the server sending the broadcast only sends 1 copy of the packet, no mater how many people are needing it |
| [03:09:55] | knightr: | yikes but expected since this is multicast... |
| [03:10:24] | clever: | within that multicast is the rtp streams containing the tv audio/video |
| [03:10:42] | clever: | it looks like every multicast group is a seperate TS, containing 1 or more channels |
| [03:11:08] | clever: | wireshark can show the PID's within the rtp stream, and claims it isnt scrembled |
| [03:11:53] | SteveGoodey (SteveGoodey!~steve@host86-145-236-203.range86-145.btcentralplus.com) has joined #mythtv | |
| [03:11:56] | knightr: | ?? Who's right, wireshark or MythTV? |
| [03:12:17] | knightr: | Do you have anything else that could process it? |
| [03:13:29] | clever: | vlc and mplayer both hang forever and say nothing about encryption |
| [03:14:28] | clever: | they just complain about different things |
| [03:14:30] | knightr: | and you are sure it's not corrupted in any way? |
| [03:14:59] | clever: | its running over the same path as the internet, and everything is crc'd to death at several layers |
| [03:15:40] | clever: | just at a glance, i see a crc in the IP packet, oh, thats it |
| [03:17:27] | clever: | open http://ext.earthtools.ca/fibreop/capture in wireshark and set it to decode as RTP |
| [03:19:28] | knightr: | why do I have a feeling my little atom cpu on the netbook I currently have to use is going to barf on this... :) |
| [03:20:05] | clever: | oh wait, i uploaded the wrong capture file |
| [03:20:23] | clever: | ok, fixed it |
| [03:22:21] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 264 seconds) | |
| [03:23:09] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [03:30:30] | knightr: | I see no mention of the content being encrypted (but would it report it if it were?) |
| [03:31:11] | clever: | there is a field in there to say if it is scrambled or not, but that one is set to no scrambling |
| [03:31:27] | clever: | myth mentions that the encryption is enabled within the program map table, but wireshark cant decode that |
| [03:32:12] | knightr: | so both could be right... |
| [03:33:03] | CeilingKitten (CeilingKitten!~CeilingKi@206-248-157-46.dsl.teksavvy.com) has joined #mythtv | |
| [03:33:32] | SteveGoodey (SteveGoodey!~steve@host86-145-236-203.range86-145.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [03:35:26] | knightr: | do you know if that specific rtp stream is supposed to be encrypted or not? |
| [03:35:55] | knightr: | (or know of one which is and one which isn't to be able to compare...) |
| [03:36:12] | clever: | nope |
| [03:36:40] | clever: | all i can do right now is see what multicast ip its currently using and copy it over |
| [03:37:03] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [03:37:56] | clever: | also, several of my switches handle multicast poorly, and lag like hell if any multicast has to pass thru them :( |
| [03:39:00] | knightr: | and you can't temporarily bypass some of them? |
| [03:39:14] | dgeary2 (dgeary2!~debian@pa49-187-82-9.pa.nsw.optusnet.com.au) has quit (Quit: Ex-Chat) | |
| [03:39:40] | clever: | knightr: i wired all of the devices needing multicast directly into the main router |
| [03:39:52] | clever: | so they are isolated from anything sensitive to lag, and on the hardware the ISP provides |
| [03:41:51] | knightr: | that feed, what is it normally supposed to be processed with? There must be a way to test it... |
| [03:42:15] | clever: | its normaly ran by a set top box running windows CE |
| [03:42:25] | clever: | which has no debug controls or any way to feed it an rtp url |
| [03:43:13] | clever: | atleast none that ive found |
| [03:44:37] | jya: | dekarl: which issue is that? the rewind in livetv or playback not exiting when reaching EOF, or something else? |
| [03:45:38] | knightr: | OK, looks like you can emulate a RPT feed with Videolan (see http://www.mythtv.org/wiki/IPTV), you might want to test how MythTV currently deals with it... |
| [03:46:15] | knightr: | (so you would know if there's not something currently broken) |
| [03:46:28] | jya: | knightr: you mean rtp? |
| [03:46:47] | knightr: | jya, yep... |
| [03:47:07] | clever: | jya: trying to get rtp to work in myth, with a feed provided by my isp |
| [03:47:08] | knightr: | wireshark seems to think the feed is not encrypted, MythTV think it is... |
| [03:47:40] | jya: | clever: rtp was working in 0.26, that I'm sure about as I was using it… Haven't been able to test since the rewrite of iptv |
| [03:48:09] | clever: | jya: i'm not sure if the problem is the PID's being encrypted or something else |
| [03:48:25] | clever: | jya: what kind of debug can i do to print the PMT? |
| [03:48:35] | knightr: | jya, know of any test feed that could be used to check if it still works A-OK? |
| [03:48:42] | jya: | clever: well, that would be an issue in the mpeg-ts stream rather than the iptv stream |
| [03:49:06] | clever: | jya: http://privatepaste.com/70c0af314c is the output from one of the rtp streams i tried |
| [03:49:21] | knightr: | (apart from the Videolan emulation mentioned here http://www.mythtv.org/wiki/IPTV that is...) |
| [03:49:29] | jya: | jya: problem with most rtp/udp stream, is that it comes from your ISP… and I've changed ISP and have no access to any IPTV stream (which is what pushed me in writing the HLS recorder) |
| [03:50:03] | jya: | so using videolan would certainly be a good test, though I doubt it would be a multicast stream |
| [03:50:49] | jya: | anyone in Australia with TPG as ISP? |
| [03:51:56] | jya: | clever: are you sure that stream isn't encrypted? there are two issues at play here. The IPTV stream and the decoding of the mpeg stream… That you are getting to that error shows that the IPTV transport seems to work… it's the content you get that isn't good |
| [03:52:40] | clever: | jya: no clue, i was trying to write a c program that would give a simple yes/no, so i could test them in bulk |
| [03:52:43] | clever: | but i'm stuck trying to find the size of an mpegts payload |
| [03:52:56] | clever: | payload dword1 4740221b pid:22 adap:1 CC:11 start:1 |
| [03:52:57] | jya: | it's 188 bytes |
| [03:53:03] | clever: | its always 188 bytes? |
| [03:53:08] | jya: | yes. |
| [03:53:21] | clever: | that explains why i couldnt find any trace of the lenght |
| [03:53:58] | jya: | http://en.wikipedia.org/wiki/MPEG_transport_stream |
| [03:54:06] | clever: | yep, thats what i'm reading |
| [03:54:14] | knightr: | I gotta go sleep guys, good night/day! |
| [03:54:19] | clever: | it just says the payload data is 0 or mote, depends on flags |
| [03:55:27] | jya: | if you want a mepg ts stream and you have no DVB adapter on your machine, you can do so with the HLS player |
| [03:55:47] | jya: | you can easily modify it to record the data it receives to disk |
| [03:56:31] | jya: | clever: what exactly are you trying to do? |
| [03:56:50] | clever: | jya: get mythtv to play/record all the iptv channels i have |
| [03:57:26] | jya: | clever: forgetting the playlist and the recorder.. have you first tried using mythavtest? |
| [03:57:39] | jya: | like so: mythavtest rtp://blah |
| [03:57:46] | jya: | or mythavtest udp://blah |
| [03:57:58] | clever: | ah, that would have been usefull to know 3 hours ago, lol |
| [03:58:09] | clever: | let me hook a monitor up to the myth box and try that |
| [03:58:12] | jya: | don't add the @ before the address (like what VLC expects) |
| [03:58:32] | jya: | you can also try mythffplay |
| [03:58:43] | jya: | need to compile myth with --enable-sdl |
| [03:59:03] | jya: | or if you have ffmpeg/libav installed, ffplay rtp://... |
| [03:59:20] | jya: | if it doesn't play there, at least that tells you there's no point trying the recorder |
| [03:59:22] | clever: | mplayer and vlc just hang with various non-encryption related errors |
| [03:59:57] | clever: | i'll try mythavtest once i get a monitor and X up on that box |
| [04:00:17] | jya: | there's no much point ttrying to record it unless you can play it.. and not being able to play it indicates issues the recorder would fail to resolve too... |
| [04:00:32] | jya: | one step at a time |
| [04:04:38] | jya: | paul-h: for an error, you should be using a MythErrorNotification instead of MythNotification |
| [04:06:47] | clever: | jya: ok, going to hook up a monitor... |
| [04:07:51] | ** jya drums rolling ** | |
| [04:09:31] | clever: | startx, command not found |
| [04:09:44] | clever: | guess this box has been headless for too long, lol |
| [04:10:11] | jya: | why don't you just ssh -X to it from another box? |
| [04:10:21] | jya: | for the purpose of testing if you get a video, that's enough |
| [04:10:29] | clever: | i dont expect X11 tunneling over wifi to handle video very well |
| [04:10:49] | clever: | and even pushing compressed mpegts over the wifi completely floods the link |
| [04:11:04] | jya: | don't really need to if all you're after it testing if there's a video coming in… just seeing the few first frames will be enough |
| [04:11:14] | clever: | let me try that |
| [04:11:21] | jya: | with an IPTV stream? very unlikely |
| [04:11:36] | jya: | unless it's a multicast stream |
| [04:11:50] | jya: | in which case just have a wireless stream will be enough to put your network to a crawl |
| [04:11:51] | clever: | it is multicast |
| [04:12:12] | jya: | what's your wireless access point? |
| [04:12:19] | clever: | g band |
| [04:12:23] | jya: | that's probably your problem to start with |
| [04:12:37] | jya: | by default with a g wireless adapter, the multicast rate is 1Mbit/s only |
| [04:12:40] | clever: | the ISP gave me an N band router with isolation enabled |
| [04:12:45] | clever: | so i cant access ANYTHING on the wired lan |
| [04:12:58] | jya: | so trying to stream a multicast stream, with just having a wireless network present will kill your connectivity |
| [04:14:50] | clever: | jya: http://privatepaste.com/311ae92c51 |
| [04:14:58] | jya: | so to test you will either have to turn off your wireless router, increase the multicast rate to 11Mbit/s (that's usually enough), or enable igmp snooping if your router allow |
| [04:14:59] | clever: | just exits without any errors |
| [04:15:05] | jya: | I wrote something about it a while back: http://www.avenard.org/iptv/TPG_and_IPTV/IPTV_and_Wireless.html |
| [04:15:31] | clever: | the hardware the isp provided does igmp snooping, so it wont spam the un-needed segments |
| [04:15:41] | jya: | mythavtest -v audio,playback,libav --loglevel=debug |
| [04:15:47] | clever: | i already had to rewire things so that the multicast had a dedicated path |
| [04:15:53] | clever: | so it wouldnt lag synergy/ssh |
| [04:16:20] | jya: | clever: good… i had a great deal of trouble watching multicast stream back then when I had a wireless |
| [04:16:38] | jya: | in the end, I bought a level 3 gigabit switch that gave me igmp snooping |
| [04:16:47] | clever: | the main problems ive had so far, is that the router refused to change its subnet to 10.0.0.0/25 |
| [04:16:56] | clever: | so i had to reconfigure the static ip and config files on 5+ systems |
| [04:17:12] | jya: | clever: restart your mythavtest with the logging option above |
| [04:17:12] | clever: | 2nd, the router cant port forward traffic from inside the lan, so i didnt notice one site was down for a week |
| [04:17:25] | jya: | it could be that mythavtest doesn't recorgnise rtp:// url |
| [04:17:27] | clever: | jya: http://privatepaste.com/80afafa7b5 |
| [04:17:53] | jya: | is that it ??? |
| [04:17:54] | clever: | is starting to look like that |
| [04:18:02] | clever: | yep, thats the full output |
| [04:18:28] | jya: | now that's weird… but you would get more useful log with 0.27, I added much more info in the output there |
| [04:18:44] | jya: | so try with ffplay or mythffplay |
| [04:18:59] | clever: | -bash: mythffplay: command not found |
| [04:19:06] | clever: | -bash: ffplay: command not found |
| [04:19:22] | jya: | you need to compile with with --enable-sdl (and have the sdl library installed obviously) |
| [04:19:27] | jya: | well, install ffplay ! |
| [04:19:44] | clever: | maybe i'll just update to 0.27 |
| [04:19:47] | jya: | yes, there's nothing for myth to handle the rtp:// stream |
| [04:20:01] | jya: | so mythavtest will never handle those streams directly :( |
| [04:20:06] | jya: | try with udp:// |
| [04:20:34] | jya: | which it doesn't handle either :) |
| [04:20:40] | clever: | same thing |
| [04:20:42] | jya: | so your best bet at this stage. |
| [04:20:51] | jya: | try with with ffplay/mythffplay |
| [04:21:03] | jya: | 2nd: use udp:// instead of rtp:// |
| [04:21:12] | jya: | in your recorder playlist |
| [04:21:40] | clever: | i was using a custom m3u file supplied to mythtv-setup as an iptv source, and it did seem to be capable of parsing the PMT headers |
| [04:22:02] | clever: | http://ext.earthtools.ca/test.m3u |
| [04:22:19] | jya: | i just found that using udp:// is often what's required to make it work |
| [04:22:40] | clever: | let me enable network support in ffmpeg and see what that does |
| [04:22:55] | jya: | try the following patch for mythavtest |
| [04:22:56] | clever: | have you seen the packet captures yet? |
| [04:24:05] | clever: | http://ext.earthtools.ca/fibreop/capture |
| [04:24:07] | jya: | http://privatepaste.com/2deda7bcf2 |
| [04:26:23] | clever: | compiling... |
| [04:27:01] | jya: | may commit that change too… it can be useful |
| [04:27:11] | clever: | you forgot a || |
| [04:27:18] | jya: | was just thinking that :) |
| [04:27:44] | jya: | actually, I do have it here… just my copy/paste of git diff was too large for my terminal |
| [04:27:50] | clever: | ah |
| [04:29:04] | jya: | http://privatepaste.com/2967235c2c |
| [04:29:26] | clever: | already compiled |
| [04:29:29] | clever: | just waiting on the install |
| [04:30:10] | clever: | no effect |
| [04:30:58] | jya: | there should be something in the log |
| [04:31:06] | clever: | hmmm, the exit code is 138, does that mean anything? |
| [04:31:12] | clever: | 2013-08–11 01:31:00.142420 E MythUIHelper: Could not find theme: – Switching to Terra |
| [04:31:19] | clever: | maybe we shouldnt be ignoring the final line? |
| [04:32:15] | jya: | regardless, there should be an error somewhere |
| [04:32:29] | jya: | with -v libav there would be the reason why it failed |
| [04:32:50] | clever: | if i give it an http url, the access.log shows no hits |
| [04:33:22] | jya: | not surprising… this is all done within ffmpeg, so it never access our own read/write routine |
| [04:33:49] | jya: | there should be a "Failed to open stream blah…" with the patch I've given you |
| [04:34:19] | clever: | jya: http://privatepaste.com/4d8fd2d991 |
| [04:34:44] | jya: | if you have to add: DISPLAY=ramboot.localnet:0 LD_LIBRARY_PATH=/home/mythtv/test/ mythavtest -v audio,playback,libav --loglevel=debug udp://239.42.134.184:8208 |
| [04:35:05] | jya: | then it should be: DISPLAY=ramboot.localnet:0 LD_LIBRARY_PATH=/home/mythtv/test/lib /home/mythtv/test/bin/mythavtest -v audio,playback,libav --loglevel=debug udp://239.42.134.184:8208 |
| [04:35:20] | clever: | ~/test/ is just an ugly hack arround a udev lib |
| [04:35:27] | jya: | what's your configure line? |
| [04:35:40] | clever: | lrwxrwxrwx 1 mythtv mythtv 19 Aug 6 22:15 libudev.so.0 -> /usr/lib/libudev.so |
| [04:35:43] | clever: | its linked against an older version, which doesnt exist anymore |
| [04:36:01] | clever: | just plain ./configure, no arguments at all |
| [04:37:23] | clever: | aha!, a hint |
| [04:37:24] | clever: | 2013-08–11 01:35:06.593423 E Fatal Error: Audio not configured, you need to run 'mythfrontend', not 'mythtv'. |
| [04:37:40] | clever: | it gave this when i ran it in gdb, while trying to get a backtrace |
| [04:37:48] | clever: | it looks like it was quiting before the log buffer could fully print? |
| [04:38:00] | clever: | gdb added delays, causing the buffer to fully empty this time |
| [04:38:25] | clever: | https://github.com/MythTV/mythtv/blob/master/ . . . ain.cpp#L224 |
| [04:38:40] | clever: | this is the line that its failing at, due to it being a headless box, i never configured audio |
| [04:39:49] | clever: | line 225 is also wrong, its refering to itself by the wrong name |
| [04:40:35] | jya: | just run mythavtest -O AudioOutputDevice=ALSA:default ... |
| [04:40:37] | jya: | that will do |
| [04:40:56] | clever: | the other issue seems to be that the new logserver stuff is async |
| [04:41:05] | clever: | and the return on line 226 causes it to drop the last few messages |
| [04:42:06] | clever: | ok, now it does something! |
| [04:43:18] | clever: | jya: http://privatepaste.com/5048594b6a |
| [04:43:56] | clever: | ok, its claiming that there is an h264 at pid 22 and an AC3 at pid 20 |
| [04:44:01] | jya: | well, i could give you something to try with 0.27, but not with 0.26 |
| [04:44:06] | clever: | and an mp3 at pid 21 |
| [04:44:29] | clever: | then the continuity check fails a bunch of times |
| [04:44:54] | clever: | let me have a look at the rtp code... |
| [04:45:15] | jya: | with 0.27 you could try adding: -O FFMPEGTS=1 |
| [04:45:37] | jya: | this uses the original ffmpeg demuxer instead of mythtv's own, which is far more sensitive |
| [04:45:40] | clever: | let me check the sequence numbers in the rtp layer first |
| [04:46:00] | clever: | if i'm reading the logs right, it appears to be loosing the 188 byte mpeg packets within the stream |
| [04:46:13] | clever: | rtp has its own seq numbers to detect that much earlyer |
| [04:48:06] | clever: | looks like cetonrtp.cpp i think |
| [04:48:20] | clever: | yep |
| [04:49:12] | clever: | it already has sequence debug, under -v record |
| [04:51:41] | clever: | hmmmm |
| [04:52:03] | clever: | if this doesnt help, i'll try 27 |
| [04:54:52] | clever: | jya: hmmm, the formating of the debug output, and the fact that its ignoring my changes to cetonrtp.cpp |
| [04:55:01] | clever: | i think its using ffmpeg for rtp |
| [04:55:40] | clever: | jya: which branch is 0.27? |
| [04:55:41] | jya: | clever: it will be… but that only gives you the mpeg-ts stream… which is then opened using mythtv's own mpeg-ts demuxer |
| [04:55:46] | jya: | clever: master |
| [04:55:49] | clever: | ah |
| [05:10:41] | jya: | 0.27 allows you to select which mpegts demuxer to use |
| [05:15:39] | jya: | stuartm: seems that eb78c7bda7c1859831997a54a3e3eadbb0993dd7, broke HLS recorder |
| [05:17:31] | jya: | and 277feb598e975d43c68f4b0a042a3ce6d5fd48bb too |
| [05:18:05] | jya: | can't change channels anymore |
| [05:18:26] | clever: | i'll try -O FFMPEGTS=1 after the compile is done |
| [05:18:40] | clever: | 2013-08–11 01:54:15.231442 D [mpegts @ 0xb76db300] Continuity check failed for pid 34 expected 10 got 11 |
| [05:18:45] | clever: | but if i'm reading the log right, it appears to have lost an mpegts packet? |
| [05:19:11] | jya: | in 0.27, the itpv code has changed completely... |
| [05:19:19] | jya: | full rewrite |
| [05:19:28] | clever: | ah |
| [05:19:46] | clever: | compile has begun |
| [05:57:28] | clever: | http://en.wikipedia.org/wiki/MPEG_transport_stream#Packet |
| [05:57:41] | clever: | jya: is the Continuity counter within a PID, or the entire TS? |
| [05:58:32] | clever: | my debug program seems to show that its within a PID, http://privatepaste.com/325cff2cad |
| [06:07:08] | clever: | jya: also, the 188 byte mpegts packets, are they 8 bytes of header and 180 bytes of data? |
| [06:08:00] | clever: | hmmm, wireshark says 4 bytes of header and 184 bytes of data,*tries* |
| [06:14:12] | clever: | now that i think of it, i can just dump the full mpegts, hmmm |
| [06:29:12] | clever: | ./tsinfo /tmp/mp3 Found 0 PAT packets and 0 PMT packets in 10000 TS packets |
| [06:29:40] | clever: | ok, it appears to be able to read the TS packets from my custom dump, and its oddly missing PMT and PAT's |
| [06:29:45] | clever: | yet myth logs claim it found a PMT |
| [06:36:26] | wilmoore-misc (wilmoore-misc!~wilmoore@67.190.17.108) has joined #mythtv | |
| [06:40:24] | dekarl: | jya, the "mythweb show an error instead of a list of recorded progams" is hoefully gone |
| [07:19:44] | jya: | dekarl: ah ok |
| [07:20:00] | jya: | wouldn't this also have been present in earlier version of mythweb? |
| [07:20:43] | clever: | jya: ive updated to 0.27, no real change in the logs, and i cant reproduce the phantom PMT packet |
| [07:22:40] | clever: | this pastebin from ~3 hours ago claims that pid 0x22 is h264, pid 0x21 is mp3, and pid 0x20 is AC3 audio, and the size of them when i extract with tstools agrees http://privatepaste.com/5048594b6a |
| [07:23:00] | clever: | but myth isnt showing the same info again, and the tstools also cant find that info |
| [07:29:12] | clever: | ah, its showing it differently now |
| [07:29:40] | clever: | http://pastebin.mozilla.org/2830181 |
| [07:45:47] | clever: | jya: no clue how 'normal' this is, but i verified thru wireshark that it is skipping packets of pid 0x21 (CC skipped 2), even when the RTP seq numbers dont skip anything |
| [07:46:06] | jya: | no idea |
| [07:46:34] | jya: | looks like you have dropped packets somewhere |
| [07:46:48] | clever: | but the seq numbers in the rtp stream show no signs of dropped packets |
| [07:46:50] | jya: | what is skipping packet? myth? |
| [07:47:02] | jya: | or that's what you're receiving from the source? |
| [07:47:04] | clever: | i double checked the raw data with a custom app and wireshark |
| [07:47:18] | clever: | there are mpegts packets missing inside the rtp stream |
| [07:47:29] | clever: | i can give you a short pcap file with an example |
| [07:47:30] | jya: | well, take it up to your isp then |
| [07:47:43] | jya: | nothing we can do about it |
| [07:47:57] | clever: | but how can the STB play this without any issue? |
| [07:48:29] | jya: | because it's unlikely to take it from an rtp stream |
| [07:48:52] | clever: | ive checked with tcpdump in the path, the STB is using rtp |
| [07:48:55] | jya: | also, IRC, rtp is supposed to handle requesting resend. |
| [07:49:25] | jya: | I don't believe our RTP handler does so, and it seems neither is ffmpeg |
| [07:49:40] | clever: | from the way things behave, it looks like the server is just blasting out rtp packets over multicast blindly |
| [07:49:46] | jya: | did you use mythavtest with the patch to allow to directly open the rtp stream? |
| [07:49:48] | clever: | and it expects the fiberoptic network to have 0 loss |
| [07:49:59] | clever: | yeah, it did the same as 0.26 |
| [07:50:11] | jya: | at the end of the day, youve tried with mplayer, vlc, ffmpeg and myth.. none of them get something proper |
| [07:50:40] | clever: | i also use a custom app to dump the mpegts stream, then tstools to extract each pid from that |
| [07:50:51] | clever: | ffmpeg and mplayer cant identify the streams that myth said where h264, ac3, and mp3 |
| [07:52:40] | clever: | jya: http://ext.earthtools.ca/fibreop/capture5 can you look at packets 966, 980, 985, and 994? |
| [07:52:43] | clever: | just set wireshark to decode it as rtp |
| [07:54:50] | dekarl: | jya, yes, it should have been an issue earlier. Maybe we changed something in the timing so it happens more often now. |
| [07:55:39] | SteveGoodey (SteveGoodey!~steve@host86-145-236-203.range86-145.btcentralplus.com) has joined #mythtv | |
| [07:55:49] | jya: | clever: unlikely.. mplayer, ffplay, mythavtest all share the same code |
| [07:56:40] | clever: | jya: where can i find docs on mp3 ac3 or h264, so i could attempt to verify the contents truely are what myth claimed they where? |
| [07:56:59] | dekarl: | clever, you have a broken MP3 and good AC3 audio stream? Maybe the STB is simply using the AC3 over MP3 (same as mythtv should default to) Without seeing the PMT I'll just guess its that AC3 is the correct language and MP3 is the audio for the hard of hearing or similar? |
| [07:57:54] | clever: | dekarl: oddly, the tstools cant find a single PMT packet in the stream, let me check the AC3 one |
| [07:58:06] | clever: | pid 0x20 should be ac3 |
| [07:58:40] | clever: | CC jumped from 9 to 12 on pid 0x20 |
| [07:58:44] | clever: | nope, the AC3 PID is also skipping packets |
| [07:58:46] | jya: | clever: youre confusing many things and taking the wrong approach about it… on one hand you have the transport layer (here rtp), then you have the container (here mpeg-ts) and then you have the codecs… you're mixing everything up … you won't solve your isues like this |
| [07:59:12] | clever: | acording to the debug info in http://privatepaste.com/5048594b6a pid 0x20 should be ac3 audio |
| [07:59:20] | clever: | and pid 0x22 should be h264 encoded video |
| [07:59:23] | clever: | am i reading it right? |
| [08:00:26] | dekarl: | sounds right, with -v record MythTV will log what its getting as PMT |
| [08:01:22] | dekarl: | but if you get missing TS packets without missing RTP packets in wireshark&co then the issue is upstream |
| [08:01:40] | clever: | i wrote a custom program to dump the mpegts stream inside rtp, and tstools seems to think its valid |
| [08:01:44] | clever: | http://privatepaste.com/ad4023033d |
| [08:01:51] | clever: | it cant find a single PMT or PAT packet in a 5 minute+ file |
| [08:02:35] | dekarl: | btw, mythutil can look at the various PIDs, too. |
| [08:03:41] | clever: | clever@ramboot ~/builds/tstools/bin $ ./ts2es -pid 0x22 ~/fibreop/mpegts ~/fibreop/0x22 |
| [08:03:50] | clever: | -rw-r--r-- 1 clever clever 107M Aug 11 05:03 0x22 |
| [08:04:13] | jya: | clever: at the end of the day, this has little to do with mythtv development, so maybe you should take this to #mythtv-users |
| [08:04:15] | clever: | and if i extract what myth claims was video, i do get a file that is nearly 90% of the original mpegts size |
| [08:05:42] | dekarl: | (04:50:50) clever: 2013-08–07 19:09:15.243973 N DTVSM(): PMT says program 8208 is encrypted |
| [08:05:42] | dekarl: | that might lead to all funny issues when you don't decode if I understand correctly |
| [08:06:13] | clever: | dekarl: ive tried to verify that it is indeed encrypted, but i cant find a single PMT packet anywhere |
| [08:06:26] | clever: | so i have no idea how myth found that info |
| [08:07:41] | dekarl: | PAT/PMT are mandatory tables, without them you have bigger issues (how do the tools know where they find H.264, MP3, AC3? |
| [08:08:13] | clever: | and how did myth even know 0x22 was h264? |
| [08:08:26] | clever: | mythtv seems to be finding PMT tables that i cant find |
| [08:08:44] | clever: | where are they usualy hidden in a mpegts stream, under a dedicated pid? |
| [08:13:49] | dekarl: | clever, find the PMT on PID 0, it lists the PIDs that carry all programs/services PMTs. (two special program_numbers with program 0 being NIT, program -1 being the encrypted EIT) |
| [08:14:33] | dekarl: | <hint>mythutil --pidprinter --pids 0 --infile THEFILE</hint> then add more PIDs as you go |
| [08:19:03] | clever: | dekarl: aha, i had the bytes swapped for a size field, which is only present on PMT packets |
| [08:19:40] | dekarl: | clever, if you want to fiddle with the bitstream you must have the specs handy. there is a lot of bit fiddling going on in MPEG land |
| [08:20:27] | clever: | i was going by the specs on wikipedia, but i had the bytes in an rtp header backwards |
| [08:20:43] | clever: | and the rtp header seems to have some extra data only on the packets carrying PMT |
| [08:20:54] | clever: | so i was selectively corrupting only the data i wanted, *facepalm* |
| [08:22:53] | dekarl: | aye, thats what I'm refering to, lots of "if bit6=1 then you have 5 extra bits after bit 18" stuff |
| [08:24:09] | clever: | yep, in this case it was a 16 bit size field, that was usualy 0000, so having it backwards was harmless 90% of the time |
| [08:38:34] | stoffel (stoffel!~quassel@pD9E40039.dip0.t-ipconnect.de) has joined #mythtv | |
| [08:42:28] | clever: | dekarl: found it, pid 0 is the PAT, which then points to a PMT in pid 0x23 |
| [08:45:48] | clever: | yep, this stream i'm looking at is encrypted |
| [08:50:14] | SteveGoodey (SteveGoodey!~steve@host86-145-236-203.range86-145.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [08:51:07] | SteveGoodey (SteveGoodey!~steve@host86-145-236-203.range86-145.btcentralplus.com) has joined #mythtv | |
| [08:51:10] | dgeary2 (dgeary2!~debian@pa49-187-82-9.pa.nsw.optusnet.com.au) has joined #mythtv | |
| [08:52:13] | SteveGoodey (SteveGoodey!~steve@host86-145-236-203.range86-145.btcentralplus.com) has quit (Client Quit) | |
| [08:55:36] | SteveGoodey (SteveGoodey!~steve@host86-145-236-203.range86-145.btcentralplus.com) has joined #mythtv | |
| [09:11:58] | jya: | Captain_Murdoch, stuartm : all the changes to MDM has broken the HLS recorder.. Having a hard time trying to pinpoint the issue… Seems that in the backend, in the recorder code, there isn't any QEventLoop running. So the cancellation of a download never ends and the HLS RingBuffer is waiting forever for the download to be completed. so you can tune once, any further re-tune will block |
| [09:13:43] | jya: | so when using a simply queue or something that would cause the cancel to occur immediately, it was all good... |
| [09:17:46] | stuartm: | so it's the signal that's not working? We could change that so instead there is a periodic call to clear up the cancellation queue, but I'm not sure where that should be done and whether the delay would be tolerable for the HLS recorder |
| [09:18:23] | stuartm: | alternatively we make sure there is an event loop running |
| [09:18:25] | jya: | ah… I think I see what's going on… the HLS ringbuffer loop to cancel all downloads, at some stage the MDM has nothing to download and it enter an infinite wait (waiting for the next download queue to start). But the HLS encoder loop through all its URL to cancel |
| [09:18:57] | jya: | so once the MDM isn't downloading, the cancelurl is blocked waiting forever |
| [09:19:30] | stuartm: | ah |
| [09:20:05] | jya: | stuartm: with your changes to MDM, things are even worse.. I went back to my previous code, changing for the BlockingQueuedConnection gets me much further |
| [09:20:47] | jya: | seems that the way to fix it is to either not call cancel on a url that isn't downloading, or modify the MDM to just ignore those |
| [09:21:56] | SteveGoodey (SteveGoodey!~steve@host86-145-236-203.range86-145.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [09:22:25] | jya: | i think the issue with queuing the cancel, is that the HLS RingBuffer calls cancel in its destructor |
| [09:22:51] | jya: | so it expect the cancel to occur right away which would awake the HLS download thread. |
| [09:23:23] | clever: | i have verifyed that this specific RTP stream is encrypted, and i can see how to detect it, so no chance of getting myth to record it, but i know enough now to bulk check channel |
| [09:23:23] | jya: | otherwise the delete occurs, then the MDM blocking download gets out but by then the current instance has been deleted |
| [09:23:31] | jya: | that cause some "weird" behaviour |
| [09:23:37] | dekarl (dekarl!~dekarl@p4FCEE89C.dip0.t-ipconnect.de) has quit (Ping timeout: 240 seconds) | |
| [09:23:46] | clever: | not much more myth can do enless i find a CA card that bless |
| [09:23:56] | clever: | that they* |
| [09:24:21] | jya: | stuartm: not sure of the best way to fix that one… revert your change and go back to a blocking cancel, adding the test to not try to cancel anything if there's nothing being downloaded... |
| [09:24:39] | jya: | or try to handle the fact that a cancel is queued. |
| [09:31:49] | paul-h (paul-h!~Paul@176.253.145.244) has joined #mythtv | |
| [09:38:26] | dekarl (dekarl!~dekarl@p4FCEEC95.dip0.t-ipconnect.de) has joined #mythtv | |
| [09:39:55] | jya: | stuartm: suggestions? |
| [09:41:21] | jya: | if I go with the first one (making it a blocker) can you test the problem there was with one of the plugin ? |
| [09:43:54] | exoon (exoon!~exoon@p4FD4328D.dip0.t-ipconnect.de) has joined #mythtv | |
| [09:45:34] | stuartm: | going back to trying the blocking connection is fine, I can check that it doesn't break mythnews |
| [09:52:04] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv | |
| [09:52:52] | paul-h: | jya: thanks for the patch I should have known about that after the discussion on the theme list :) |
| [10:01:31] | stoffel (stoffel!~quassel@pD9E40039.dip0.t-ipconnect.de) has quit (Ping timeout: 260 seconds) | |
| [10:25:56] | jya: | paul-h: afterall, you're the one who suggested those notifications ! |
| [10:35:46] | paul-h: | jya: haha yeah that makes it even worse :) |
| [10:37:08] | paul-h: | Does anything stand out as being wrong in the use of ffmeg here http://code.mythtv.org/cgit/mythtv/tree/mythp . . . in.cpp#n1949 |
| [10:37:52] | paul-h: | It segfaults every time in estimate_timings_from_pts() |
| [10:38:38] | paul-h: | It's been working OK for years now it's suddenly started to segfault |
| [10:41:46] | paul-h: | This is the bt http://pastebin.com/FiGnTm3q as you can see st->info is in the problem |
| [10:48:44] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [10:58:56] | SteveGoodey (SteveGoodey!~steve@host86-145-236-203.range86-145.btcentralplus.com) has joined #mythtv | |
| [11:09:43] | stuartm: | thinking of adding a 'recently watched' list to the views available in Watch Recordings, all too often I start watching something only to be interrupted, when I go back to watch the other half it's always a pain to find it in the list |
| [11:11:03] | stuartm: | then there are the recordings I started watching but simply forgot about so they remain half-watched for weeks or months |
| [11:19:50] | Tobbe5178: | another thing that would be nice to have is to be able to sort the recordings of a series by season & episode, for example if they are being transmitted in a strange order or you started the recording somewere in the middle of a season and you get the first part via reruns later |
| [11:20:38] | dekarl: | Tobbe5178: just change the sorting order ;) |
| [11:20:50] | Tobbe5178: | or if different seasons is being transmitted at the same time on different channels so you end up with a list that is mixed |
| [11:22:33] | Tobbe5178: | dekarl: how? can it be done directly from the watch recording screen? |
| [11:23:00] | dekarl: | its under "View Recordings (4/8)" "Sort episode: Season/Episode" |
| [11:24:56] | Tobbe5178: | i assume thats in the normal settings somewere? |
| [11:26:01] | dekarl: | frontend->configuration->video->playback |
| [11:30:02] | dekarl: | knightr: can I give this to you for after the branch point? git grep "[aA]s Unwatched" |
| [11:30:41] | wilmoore-misc (wilmoore-misc!~wilmoore@67.190.17.108) has quit (Remote host closed the connection) | |
| [11:31:52] | Tobbe5178: | dekarl: thanks, i should have known |
| [11:32:30] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [11:35:26] | jya: | paul-h: av_estimate_timing isn't an official API anymore… looking elsehwere in the code, to fill the info field, you need to call av_probe_input_format first |
| [11:43:16] | paul-h: | jya: OK thanks it actually seems to work OK if I just remove that call to av_estimate_timing so it doesn't look like it's required any more |
| [11:44:03] | jya: | not all codec seems to work without that call.. I know that in avformatdecoder.cpp it had been removed, only to be re-added later to fix bug reports |
| [11:44:28] | jya: | let me provide you with hopefully a good solution (finishing another thing right now) |
| [11:47:00] | jya: | but maybe you're right.. it's not required anymore... |
| [11:50:02] | dgeary2 (dgeary2!~debian@pa49-187-82-9.pa.nsw.optusnet.com.au) has quit (Quit: Ex-Chat) | |
| [11:52:56] | dekarl: | hmm, we don't check for NULL with lots of the iterators in mainserver.cpp e.g. #11279 is that something to fix now or after release? |
| [11:52:56] | ** MythLogBot http://code.mythtv.org/trac/ticket/11279 ** | |
| [11:53:44] | jya: | dekarl: whatever is in that list shouldn't be null to start with |
| [11:54:20] | jya: | shouldn't have to test what the iterator is pointing to... |
| [11:54:33] | dekarl: | i agree, but the backtrace suggests otherwise |
| [11:55:00] | jya: | if it's null, it points to another problem: a racing conditions somewhere, not testing that the creation of the encoder succeeded before adding to the list etc... |
| [11:58:30] | Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer) | |
| [11:59:23] | jya: | dekarl: i can't even find where that list is built :( |
| [11:59:59] | Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
| [12:00:12] | jya: | ah, it's an argument provided to MainServer constructor |
| [12:00:15] | dekarl: | tvList in main_helpers.cpp |
| [12:00:22] | natanojl: | dekarl: jya: I actually took a look at that one. It's [] operator that's constructing a default object and inserting it. I think we should be using find() instead |
| [12:01:06] | jya: | but you should always have something like list[..] = blah |
| [12:01:14] | jya: | so it's replaced appropriately |
| [12:01:40] | ** dekarl going out with the kid, laters ** | |
| [12:02:26] | jya: | hum… always done after a new.. so that value can't even be null |
| [12:03:03] | jya: | s/even/ever |
| [12:05:37] | jya: | well, i'm starting to doubt that backtrace... |
| [12:06:12] | natanojl: | But it's only inserted if tv->Init() succeeds so there can be cardids that don't have any EncoderLink in tvList |
| [12:06:34] | jya: | natanojl: that's irrelevant, because then they anre't added to the list |
| [12:07:07] | jya: | the backtrace indicates that you have a null pointer to the list |
| [12:07:14] | jya: | in the list that is |
| [12:08:55] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Quit: Ex-Chat) | |
| [12:09:46] | jya: | the only way for tvList to contains a null pointer is if new EncoderLink returned a null pointer. Which impossible (it would generate an exception) or somehow new got aliased to new (std::nothrow) |
| [12:10:02] | natanojl: | Yeah, but it is being used in scheduler.cpp as well |
| [12:10:16] | jya: | but what's provided to scheduler.cpp is the same tvlist |
| [12:10:32] | natanojl: | Check Scheduler::GetNextLiveTVDir(uint cardid) for example |
| [12:10:42] | jya: | it just passes a pointer to this list rather than usual qt of passing argument by value/reference |
| [12:11:13] | jya: | but that code is good |
| [12:11:38] | jya: | oh, I see what you mean |
| [12:12:02] | jya: | yes, that code should be replaced into m_tvList->find(cardid) |
| [12:12:22] | natanojl: | great :) |
| [12:12:51] | jya: | or something like: if (!m_tvList->contains(cardid)) return; |
| [12:14:45] | natanojl: | yes |
| [12:15:44] | jya: | I personally prefer testing if it contains something first, then fetch it for readability… but it depends on the situation, the prevent having to search the list twice |
| [12:15:48] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [12:15:58] | jya: | need to check if there are anymore of those... |
| [12:20:36] | natanojl: | Agreed. I don't think doing lookups twice is going to be expensive in this case though. It's not likely you have thousands of capture cards ;) |
| [12:26:21] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 252 seconds) | |
| [12:27:28] | exoon (exoon!~exoon@p4FD4328D.dip0.t-ipconnect.de) has quit (Ping timeout: 264 seconds) | |
| [12:27:57] | exoon (exoon!~exoon@p4FD41513.dip0.t-ipconnect.de) has joined #mythtv | |
| [12:55:46] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [13:00:28] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Quit: Gone) | |
| [13:07:10] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv | |
| [13:07:20] | knightr: | dekarl, Thank you! I can remove it right now since it does qualify as a bug fix. It even removes two strings since they are in the same context because they are in the same class... |
| [13:14:54] | knightr: | fixed... |
| [13:55:27] | jya: | knightr: shouldn't it have been the other ones to be changed? now that makes Mark as (Un)Watched unconsistent with all the other messages in that file |
| [13:56:26] | jya: | the only other place where it was showing was in videodlg.cpp, and there too, every word is in uppercase |
| [13:56:44] | jya: | so to me, you only extended the inconsistencies already there |
| [13:56:52] | knightr: | The other ones in those screens were unsing what I believe is called title case. Words such as from, as, etc.. must be lower case |
| [13:57:15] | knightr: | s/unsing/using |
| [13:57:30] | jya: | well, seeing that there's no other "as" used in a string, it's hard to know what's the default should be |
| [13:57:47] | jya: | but what's for sure, is that its now even more inconsistent... |
| [13:57:49] | jya: | just saying... |
| [13:58:33] | knightr: | where is sphery when we need him :) He was the one researching that.. :) |
| [14:00:13] | knightr: | I agree that with the rest it seems more inconsistent but AFAIK when you use that way of writing you put caps in front of every words except from, as, the, etc.. |
| [14:01:07] | jya: | i don't believe there are any definite rule on the matter… and a quick google confirms that… there are about as many rules as there are google results |
| [14:01:08] | knightr: | I am currently searching for more info about it... |
| [14:01:35] | jya: | http://grammar.about.com/od/grammarfaq/f/capitalstitle.htm |
| [14:02:16] | knightr: | Mike had a post about it on the developers ml, unfortunately I can't access the post or archives because my main pc has disk problems... |
| [14:02:50] | jya: | yeah, I remember years ago there was discussion on the development list, just before iamlindoro modified all of them |
| [14:03:17] | knightr: | ROTFL.. |
| [14:03:28] | jya: | another one from the same site: |
| [14:03:29] | jya: | http://grammar.about.com/b/2008/04/11/rules-f . . . -a-title.htm |
| [14:03:42] | jya: | so you can see with 1. and 3.; both are in use |
| [14:05:10] | knightr: | LOL, we really need to agree on a set of rules, this is getting nuts... |
| [14:07:04] | knightr: | I'll ping Mike about it so we can get the ball rolling on this after 0.27... |
| [14:07:45] | knightr: | We already have the problem with inconsistent casing in some themes so if we could all agree on what the standard should be in MythTV it would be for the best... |
| [14:08:13] | jya: | from reading a few articles, seems that what you did is the most common way |
| [14:10:01] | knightr: | IIRC that was what was suggested by Mike at the time, like you said we just need to stick to one standard (preferrably the most common one...) |
| [14:14:04] | exoon (exoon!~exoon@p4FD41513.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds) | |
| [14:27:06] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds) | |
| [14:33:10] | jya: | stuartm: if you could check mythnews after updating that would be appreciated (though I'm fairly confident it will work) |
| [14:34:14] | jya: | knightr: what's the official reason for postponing the beta? |
| [14:44:41] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [14:54:21] | stuartm: | initially it was the audio issue iirc, but there have been a steady stream of fixes going in since which each incrementally push back the beta just a little – there's nothing worse than tagging and releasing a version, even a beta, only to discover that it was broken by something committed shortly before |
| [14:55:14] | stuartm: | I think targeting tomorrow (Monday) would be good, we've traditionally aimed to tag/release at the start of the week instead of the end |
| [14:55:39] | brfranse_ (brfranse_!~brfransen@64.179.169.226) has quit (Quit: brfranse_) | |
| [14:56:06] | brfransen (brfransen!~brfransen@64.179.169.226) has joined #mythtv | |
| [15:02:22] | knightr: | stuartm, jya IIRC it was the MDM issue, the audio issue was not initially considered big enough to delay (that was before it was noticed that it affected other people beside Stuart though) but as Stuart said important fixes have to stop going in before so that it's stable enough to cut the beta.. |
| [15:03:31] | knightr: | once the beta is out there is only one week before the first RC... |
| [15:05:24] | knightr: | stuartm, It's not finished but is it what you had in mind (a cross between guidelines and a tutorial): http://www.mythtv.org/wiki/Coding_Standards#T . . . n_guidelines |
| [15:05:52] | knightr: | (if not I can only put the guidelines there and create another page for the tutorial and refer to it...) |
| [15:32:08] | dekarl (dekarl!~dekarl@p4FCEEC95.dip0.t-ipconnect.de) has quit (Ping timeout: 240 seconds) | |
| [16:13:02] | dekarl (dekarl!~dekarl@p4FCEF9CF.dip0.t-ipconnect.de) has joined #mythtv | |
| [16:26:20] | rsiebert (rsiebert!~quassel@g226062051.adsl.alicedsl.de) has joined #mythtv | |
| [16:29:30] | rsiebert_ (rsiebert_!~quassel@e179135101.adsl.alicedsl.de) has quit (Ping timeout: 264 seconds) | |
| [16:29:37] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!) | |
| [16:42:55] | exoon (exoon!~exoon@p4FD41513.dip0.t-ipconnect.de) has joined #mythtv | |
| [17:53:08] | exoon (exoon!~exoon@p4FD41513.dip0.t-ipconnect.de) has quit (Quit: Verlassend) | |
| [18:13:01] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has quit (Quit: Leaving) | |
| [18:14:46] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has joined #mythtv | |
| [18:17:59] | nyloc (nyloc!~quassel@p3EE2C4C7.dip0.t-ipconnect.de) has joined #mythtv | |
| [18:20:04] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has quit (Remote host closed the connection) | |
| [18:27:05] | Vink (Vink!~vink@2001:788:2:102:8465::8) has joined #mythtv | |
| [18:27:38] | Vink (Vink!~vink@2001:788:2:102:8465::8) has left #mythtv () | |
| [18:32:13] | SteveGoodey (SteveGoodey!~steve@host86-145-236-203.range86-145.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [18:39:15] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has joined #mythtv | |
| [19:04:13] | skd5aner: | knight, jya, sphery: you migth want to check out the Official Musicbrainz guidelines on capitalization... might be worth mimicing – it's worked really well for Album and Release titles – http://musicbrainz.org/doc/Style/Language/English |
| [19:04:27] | skd5aner: | dekarl: ^ |
| [19:06:16] | skd5aner: | er, knightr ^ |
| [19:22:58] | toeb (toeb!~toeb@HSI-KBW-078-042-206-116.hsi3.kabel-badenwuerttemberg.de) has joined #mythtv | |
| [19:23:56] | Vink (Vink!~vink@2001:788:2:102:8465::8) has joined #mythtv | |
| [19:28:01] | Vink: | Hi again... I've mre time to debug my EIT/EPG issue... I've finished to recompile my mythtv 0.26 with patch similar to #9592 (with my network ID) and I've no EPG displayed |
| [19:28:01] | ** MythLogBot http://code.mythtv.org/trac/ticket/9592 ** | |
| [19:28:24] | Vink: | I've copied the output of dvbsnoop here: http://www.mon-net.org/dvbsnoop-0x11.txt http://www.mon-net.org/dvbsnoop-0x12.txt |
| [19:29:12] | Vink: | Any idea where I've to look at ? my dtv_multiplex table and channel table seems fine |
| [20:39:41] | Vink: | ok. with http://code.mythtv.org/trac/ticket/9592#comment:3 , i've my epg. I've forgotten to patch libs/libmythtv/mpeg/dvbstreamdata.cpp |
| [20:40:53] | wilmoore-misc (wilmoore-misc!~wilmoore@c-67-190-17-108.hsd1.co.comcast.net) has joined #mythtv | |
| [21:01:15] | xris (xris!~xris@mythtv/developer/xris) has quit (Excess Flood) | |
| [21:01:36] | xris (xris!~xris@xris.forevermore.net) has joined #mythtv | |
| [21:19:54] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [21:23:24] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 276 seconds) | |
| [21:56:44] | Captain_Murdoch: | jya, we should be able to make MDM sleep for only the 200ms if there are any pending cancels instead of only doing that if there are current downloads. then just have the cancel queue processing done inside ::run() instead of by the event. |
| [21:57:49] | Captain_Murdoch: | jya, or instead of "if (downloading) QCoreApplication::processEvents()" inside ::run(), we "if (downloading || itemsInCancellationQueue)" or similar. |
| [21:59:52] | Captain_Murdoch: | there is no event handling thread in MDM, we handle events in ::run() by calling processEvents(). I think I did it that way due to the need to create/delete items in the same thread. |
| [22:00:52] | dekarl: | skd5aner: hehe, was about to suggest looking at the title style over at musicbrainz for inspiration, as it matches well for some of our use cases. |
| [22:06:24] | paul-h (paul-h!~Paul@176.253.145.244) has quit (Quit: Konversation terminated!) | |
| [22:22:07] | gigem_ is now known as gigem | |
| [22:22:34] | jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has quit (Quit: No Ping reply in 180 seconds.) | |
| [22:22:49] | jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has joined #mythtv | |
| [22:40:15] | knightr: | skd5aner, dekarl thank you! Mike (sphery) had suggested something similar to this a while ago but no guideline was unfortunately established... I wanted to ask Mike if we could revive this and implicate the themers as well because both the application and, more importantly, the themes are inconsistent in this regard... |
| [22:42:23] | knightr: | (it's one of the reason adding some themes add many hundreds of new strings (over 400 frequently), everybody uses a different convention, abbreviations, etc... |
| [22:45:35] | knightr: | I wish I could dig up what he posted but that was on my pc with disk problem or on a mailing list I no longer remember the URL... |
| [22:47:06] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Quit: Ex-Chat) | |
| [22:50:27] | jya: | Captain_Murdoch: i actually got up today thinking that I didn't like the solution I've pushed… it's not elegant at all; plus it may take up to 200ms for each cancel which can add up… Really need to queue things, but offer a way to block |
| [23:02:40] | jya: | going to reverse it and go back to a queue with the possibility of blocking things |
| [23:15:23] | Vink (Vink!~vink@2001:788:2:102:8465::8) has quit (Quit: [BX] Reserve your copy of BitchX-1.1-final for the ColecoVision today!) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.