| Wednesday, February 6th, 2013, 00:01 UTC | ||
| [00:01:48] | danielk22: | jya: It's probably broken then. It is not using MythSocket? |
| [00:02:09] | jya: | don't think so… let me check |
| [00:02:34] | danielk22: | Or maybe taking an socket file descriptor and using that to create the QTcpSocket ? That is safe. |
| [00:02:36] | jya: | it's been working very well… there are other areas using a separate thread and waiting for clients to connect |
| [00:02:52] | jya: | nope… no socket file descriptor |
| [00:02:56] | jya: | wou;dn't be portable either |
| [00:03:37] | jya: | actually, it uses QTcpServer |
| [00:03:49] | jya: | for TCP that is |
| [00:04:11] | danielk22: | Ok, that is different. That is intended to be used as you described.. |
| [00:04:13] | jya: | and for Udp uses QUdpSocket |
| [00:05:42] | jya: | ok.. all the Tcp socket used by AirPlay server come from what the QTcpServer sends |
| [00:06:01] | jya: | but it does create qudpsocket via the UDP api of serverpool |
| [00:06:09] | danielk22: | Right and then are only used in one thread from then on.. right? |
| [00:07:26] | jya: | yes… |
| [00:07:35] | jya: | they are not used crossed-thread |
| [00:07:45] | jya: | eg, created in one thread, and used in another |
| [00:08:03] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv | |
| [00:08:23] | danielk22: | So long as only one thread at a time touches the QTcpSocket and handoff is done safely that is perfectly safe. |
| [00:08:51] | jya: | but that's not the primary thread where the Qt event loop is running like you said earlier |
| [00:09:23] | danielk22: | So the QTcpSocket is still owned by a different thread than the worker thread, it isn't handed off ? |
| [00:10:36] | jya: | i don't know.. I don't understand the question :) |
| [00:10:37] | danielk22: | That can cause races, just imagine what happens when data arrives and is written to the internal buffer by one thread while another is reading data... |
| [00:11:00] | jya: | the thread reads the data when the signal is being received |
| [00:11:03] | dekarl: | Hmm, spend 3 hours looking at #11399 just to realize that it doesn't really do anything. The only change is completely ignoring EIT present/following unless there is a matching recording rule. |
| [00:11:03] | ** MythLogBot http://code.mythtv.org/trac/ticket/11399 ** | |
| [00:11:46] | dekarl: | I hope I'm not turning Roger away by telling him that his patch is more or less a NOOP |
| [00:12:43] | dekarl: | jya, btw. Any plans on hooking up the HLS recorder on current? (I get my Al Jazeera fix via cable now, so its more a question of curiosity) |
| [00:13:11] | danielk22: | jya: if it is handled by a direct signal then it is handled in the thread that created the QTcpSocket not the worker thread. If it is handled by any type of indirect signal then you can have races. While the signal handler is reading the data more data may arrive and corrupt the QTcpSocket instance if it is being read from the signal handler in the worker thread. |
| [00:13:17] | jya: | dekarl: what do you mean? |
| [00:13:38] | jya: | danielk22: no it's all done via signals. |
| [00:13:53] | dekarl: | jya, if I understand correctly the rewrite of IPTVRecorder in master does not include the bits to record from HLS |
| [00:14:13] | jya: | dekarl: the HLS recorder was removed? wasn't aware of it |
| [00:14:14] | danielk22: | what kind of signals? direct, queued? |
| [00:14:51] | jya: | the signal the QTcpSocket and QTcpServer send |
| [00:15:20] | jya: | like newConnection, deleteClient |
| [00:15:55] | danielk22: | Right, how is it connected? the QObject::connect call sets up how the signal is marshaled. |
| [00:16:01] | jya: | disconnected, readyRead, newDatagram (for udp) |
| [00:16:17] | jya: | like this: |
| [00:16:18] | jya: | connect(m_clientControlSocket, |
| [00:16:19] | jya: | SIGNAL(newDatagram(QByteArray, QHostAddress, quint16)), |
| [00:16:20] | jya: | this, |
| [00:16:21] | jya: | SLOT(udpDataReady(QByteArray, QHostAddress, quint16))); |
| [00:16:48] | danielk22: | Ok, it's an auto connection (http://qt-project.org/doc/qt-4.8/qt.html#ConnectionType-enum) |
| [00:16:51] | jya: | the m_clientControlSocket is a ServerPool instance |
| [00:17:11] | jya: | here, it will be from a QUdpSocket |
| [00:17:38] | danielk22: | That means the type of connection is determined by whether m_clientControlSocket and this were created in the same thread. |
| [00:17:58] | jya: | it's created like so: m_clientTimingSocket = new ServerPool(this); |
| [00:18:03] | danielk22: | (unless ownership was transferred) |
| [00:18:38] | jya: | this is a MythRAOPConnection, which inherit from QObject |
| [00:19:24] | dekarl: | jya I think it never was added to danielk22's refactor http://irc.mythtv.org/ircLog/channel/4/2012-07-31:20:41 |
| [00:19:52] | jya: | and this instance of MythRAOPConnection was created in the thread waiting for new client (which inherit from ServerPool) like so: MythRAOPConnection *obj = new MythRAOPConnection(this, client, m_hardwareId, 6000); |
| [00:19:53] | danielk22: | jya: I'd have too look at the code in detail to be sure, but I'm pretty sure this is all really single threaded. The connection is a direct connection meaning everything is done in the event thread in which m_clientControlSocket was created. |
| [00:20:12] | danielk22: | everything meaning all the socket callbacks. |
| [00:20:25] | jya: | it's in libmythtv/AirPlay/mythraop* |
| [00:20:36] | jya: | yes, everything is done via socket callbacks |
| [00:20:41] | jya: | all via signals |
| [00:20:59] | jya: | but all done in a thread that isn't the main one |
| [00:21:54] | jya: | now weither it's a bad thing or not I don't know. It's a mechanism used in several myth component, there's nothing new there.. it's started as a copy of previous code. And for what it's worth: it works well :) |
| [00:22:07] | jya: | danielk22: is the HLS recorder disable in master? |
| [00:22:13] | jya: | i'll need to have a look then |
| [00:22:37] | jya: | I got to run now… be back in a few hours |
| [00:26:02] | jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv | |
| [00:31:05] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 256 seconds) | |
| [00:33:01] | danielk22: | jya: It's mostly not there. I didn't delete the HLS RingBuffer, but pretty much figured we'd rewrite the HLS recorder when you came back. |
| [00:47:01] | stichnot (stichnot!~stichnot@67.218.104.4) has joined #mythtv | |
| [00:47:01] | stichnot (stichnot!~stichnot@67.218.104.4) has quit (Changing host) | |
| [00:47:01] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [01:10:54] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds) | |
| [01:21:16] | jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 256 seconds) | |
| [01:29:52] | Mousey (Mousey!~r0dent_@ross154.net) has quit (Quit: Read Error: Connection reset by beer) | |
| [01:49:08] | joki (joki!~joki@p54864623.dip.t-dialin.net) has quit (Ping timeout: 255 seconds) | |
| [01:49:44] | joki (joki!~joki@p5486468C.dip.t-dialin.net) has joined #mythtv | |
| [02:17:45] | Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-183-28-151.hsd1.wa.comcast.net) has joined #mythtv | |
| [02:17:45] | Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-183-28-151.hsd1.wa.comcast.net) has quit (Changing host) | |
| [02:17:45] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv | |
| [02:21:36] | dekarl (dekarl!~dekarl@p4FCEFD1B.dip.t-dialin.net) has quit (Ping timeout: 256 seconds) | |
| [02:22:35] | dekarl (dekarl!~dekarl@p4FCEFD1B.dip.t-dialin.net) has joined #mythtv | |
| [02:24:20] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has quit (Read error: Operation timed out) | |
| [02:25:35] | IReboot_ (IReboot_!~doug@99.234.145.236) has joined #mythtv | |
| [02:28:10] | Seeker` (Seeker`!~cjo20@host109-154-190-19.range109-154.btcentralplus.com) has joined #mythtv | |
| [02:28:10] | Seeker` (Seeker`!~cjo20@host109-154-190-19.range109-154.btcentralplus.com) has quit (Changing host) | |
| [02:28:10] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has joined #mythtv | |
| [02:29:20] | jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv | |
| [02:30:47] | IReboot_ (IReboot_!~doug@99.234.145.236) has quit (Quit: Ex-Chat) | |
| [02:31:09] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [02:38:26] | jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 272 seconds) | |
| [03:02:24] | toeb (toeb!~tob@HSI-KBW-37-49-118-160.hsi14.kabel-badenwuerttemberg.de) has quit (Ping timeout: 252 seconds) | |
| [03:03:17] | toeb (toeb!~tob@HSI-KBW-37-49-118-160.hsi14.kabel-badenwuerttemberg.de) has joined #mythtv | |
| [03:04:32] | stichnot (stichnot!~stichnot@adsl-68-127-102-161.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [03:04:32] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [03:04:32] | stichnot (stichnot!~stichnot@adsl-68-127-102-161.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [03:04:56] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Ping timeout: 256 seconds) | |
| [03:04:56] | Anssi (Anssi!hannulaa@mandriva/developer/anssi) has quit (Ping timeout: 256 seconds) | |
| [03:05:04] | wagnerrp_ (wagnerrp_!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv | |
| [03:05:18] | Anssi (Anssi!hannulaa@mandriva/developer/anssi) has joined #mythtv | |
| [03:05:50] | wagnerrp_ is now known as wagnerrp | |
| [03:11:48] | knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Read error: Connection reset by peer) | |
| [03:12:15] | knightr (knightr!~knightr@69-165-170-178.dsl.teksavvy.com) has joined #mythtv | |
| [03:12:15] | knightr (knightr!~knightr@69-165-170-178.dsl.teksavvy.com) has quit (Changing host) | |
| [03:12:15] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
| [04:05:20] | hsa34 (hsa34!~think@nj-76-1-235-81.dhcp.embarqhsd.net) has joined #mythtv | |
| [04:06:54] | hsa34: | i have a Ceton InfiniTV 4 usb tv tuner and it isn't working and i'm not sure how to get the device working. there seem to be drivers available. can any one point me to some documentation on it? |
| [04:13:20] | wagnerrp: | this is the development channel, try #mythtv-users |
| [04:39:24] | hsa34 (hsa34!~think@nj-76-1-235-81.dhcp.embarqhsd.net) has quit (Quit: Leaving) | |
| [04:50:41] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 248 seconds) | |
| [04:52:13] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [06:11:24] | Heikki_ (Heikki_!~heikki@94-76-207-56.static.as29550.net) has quit (Ping timeout: 244 seconds) | |
| [06:12:06] | Heikki_ (Heikki_!~heikki@94-76-207-56.static.as29550.net) has joined #mythtv | |
| [06:55:19] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [07:00:51] | dekarl1 (dekarl1!~dekarl@p4FE85CD6.dip.t-dialin.net) has joined #mythtv | |
| [07:01:03] | dekarl (dekarl!~dekarl@p4FCEFD1B.dip.t-dialin.net) has quit (Ping timeout: 256 seconds) | |
| [07:03:15] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [07:06:45] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [07:14:06] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [07:21:59] | rsiebert_ (rsiebert_!~quassel@g231184093.adsl.alicedsl.de) has joined #mythtv | |
| [07:24:52] | rsiebert (rsiebert!~quassel@g231186248.adsl.alicedsl.de) has quit (Ping timeout: 248 seconds) | |
| [07:46:23] | kwmonroe` (kwmonroe`!kwmonroe@nat/ibm/x-sdfoacjlbbyhsppo) has joined #mythtv | |
| [07:46:32] | seld (seld!~seld@h170n6-rny-a12.ias.bredband.telia.com) has quit (Ping timeout: 255 seconds) | |
| [07:46:38] | kwmonro`` (kwmonro``!~kwmonroe@32.97.110.60) has joined #mythtv | |
| [07:50:26] | kwmonroe` (kwmonroe`!kwmonroe@nat/ibm/x-sdfoacjlbbyhsppo) has quit (Ping timeout: 245 seconds) | |
| [07:50:50] | CyberJacob (CyberJacob!~CyberJaco@host-78-147-121-199.as13285.net) has joined #mythtv | |
| [07:50:51] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has quit (Ping timeout: 276 seconds) | |
| [07:51:51] | CyberJacob: | Hi |
| [07:51:57] | CyberJacob: | anybody here? |
| [07:53:39] | Tobbe5178 (Tobbe5178!~asdf@h186n5-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
| [07:53:40] | seld (seld!~seld@h170n6-rny-a12.ias.bredband.telia.com) has joined #mythtv | |
| [08:01:14] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (Read error: Operation timed out) | |
| [08:01:27] | CyberJacob (CyberJacob!~CyberJaco@host-78-147-121-199.as13285.net) has quit (Quit: CyberJacob) | |
| [08:08:26] | dekarl1 is now known as dekarl | |
| [08:10:23] | seld (seld!~seld@h170n6-rny-a12.ias.bredband.telia.com) has quit (Ping timeout: 255 seconds) | |
| [08:15:43] | Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-183-28-151.hsd1.wa.comcast.net) has joined #mythtv | |
| [08:15:43] | Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-183-28-151.hsd1.wa.comcast.net) has quit (Changing host) | |
| [08:15:43] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv | |
| [08:39:39] | seld (seld!~seld@h170n6-rny-a12.ias.bredband.telia.com) has joined #mythtv | |
| [08:40:37] | Sharky112065 is now known as Sharky-Sleep | |
| [09:13:21] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:4411:248b:88c1:f2fb) has joined #mythtv | |
| [09:17:11] | CyberJacob (CyberJacob!~CyberJaco@host-92-27-39-21.static.as13285.net) has joined #mythtv | |
| [10:07:59] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv | |
| [10:39:11] | CyberJacob (CyberJacob!~CyberJaco@host-92-27-39-21.static.as13285.net) has quit (Ping timeout: 245 seconds) | |
| [10:58:30] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Ex-Chat) | |
| [11:24:58] | neufeld` (neufeld`!~user@69-165-173-139.dsl.teksavvy.com) has joined #mythtv | |
| [11:27:23] | neufeld (neufeld!~user@69-165-173-139.dsl.teksavvy.com) has quit (Ping timeout: 255 seconds) | |
| [12:00:21] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (Ping timeout: 256 seconds) | |
| [12:10:12] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 276 seconds) | |
| [12:14:14] | Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-183-28-151.hsd1.wa.comcast.net) has joined #mythtv | |
| [12:14:14] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv | |
| [12:14:14] | Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-183-28-151.hsd1.wa.comcast.net) has quit (Changing host) | |
| [12:26:00] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Remote host closed the connection) | |
| [12:28:00] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [12:29:34] | sraue_ (sraue_!~stephan@208-48-239-77-pool.cable.fcom.ch) has joined #mythtv | |
| [12:31:02] | sraue_ is now known as sraue | |
| [12:31:12] | sraue (sraue!~stephan@208-48-239-77-pool.cable.fcom.ch) has quit (Changing host) | |
| [12:31:13] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
| [13:22:55] | jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv | |
| [13:57:06] | jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 264 seconds) | |
| [14:08:47] | DJDan (DJDan!~djdan@115-64-177-188.static.tpgi.com.au) has joined #mythtv | |
| [15:38:22] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [16:04:49] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [16:07:06] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Remote host closed the connection) | |
| [16:31:32] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [16:37:14] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG) | |
| [16:50:42] | _wilmoore_ (_wilmoore_!~wilmoore@vlandnat.mystrotv.com) has joined #mythtv | |
| [16:52:10] | stichnot (stichnot!~stichnot@67.218.104.4) has joined #mythtv | |
| [16:52:11] | stichnot (stichnot!~stichnot@67.218.104.4) has quit (Changing host) | |
| [16:52:11] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [16:53:36] | _wilmoore_ (_wilmoore_!~wilmoore@vlandnat.mystrotv.com) has quit (Remote host closed the connection) | |
| [16:53:57] | _wilmoore_ (_wilmoore_!~wilmoore@vlandnat.mystrotv.com) has joined #mythtv | |
| [16:57:48] | _wilmoore_ (_wilmoore_!~wilmoore@vlandnat.mystrotv.com) has quit (Remote host closed the connection) | |
| [16:58:05] | wilmoore-misc (wilmoore-misc!~wilmoore@vlandnat.mystrotv.com) has joined #mythtv | |
| [17:01:09] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [17:01:50] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv | |
| [17:07:28] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 240 seconds) | |
| [17:12:07] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [17:18:23] | shad0VV (shad0VV!~znc@130.43.11.219.dsl.dyn.forthnet.gr) has joined #mythtv | |
| [17:18:28] | shad0VV: | hi |
| [17:18:38] | stichnot (stichnot!~stichnot@216.239.45.73) has joined #mythtv | |
| [17:18:39] | stichnot (stichnot!~stichnot@216.239.45.73) has quit (Changing host) | |
| [17:18:39] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [17:19:26] | shad0VV: | i want to buy a dvb-t card, but i am not sure if i have to choose dvb-t or dvb-t2 card...the format which is used here in greece is mpeg-4 and we have 2 channels with 1080i |
| [17:20:39] | wagnerrp: | this is the development channel, you probably want #mythtv-users |
| [17:20:48] | shad0VV: | wagnerrp: thanks and sorry |
| [17:46:05] | Sharky-Sleep is now known as Sharky112065 | |
| [17:49:58] | stichnot: | danielk22: There is a user who is running mythcommflag --rebuild on a video but not getting any seektable entries. The reason is that the codec is identified as AV_CODEC_ID_MPEG4, and commit https://github.com/MythTV/mythtv/commit/d4cec . . . a6d0061b69aa for ticket #6817 causes seektable entries to be created only for codecs AV_CODEC_ID_MPEG[12]VIDEO and AV_CODEC_ID_H264. ... |
| [17:49:58] | ** MythLogBot http://code.mythtv.org/trac/ticket/6817 ** | |
| [17:49:59] | stichnot: | ...Do you see any reason for keeping around the can_reliably_parse_keyframes flag in AvFormatDecoder::HandleGopStart()? |
| [17:54:55] | stichnot: | danielk22: Also, there is a lot of code in avformatdecoder.cpp that changes seektable behavior when watching live TV or an in-progress recording. That doesn't seem necessary to me given that the recorder should be reliable about producing seektable info and sending regular updates to the frontend. |
| [17:57:29] | stichnot: | afaict, the idea of generating a seektable during playback is to let you easily seek back to a frame you've already played, though it doesn't help for seeking forward into new territory (all this provided the DB/recorder doesn't already have a seektable). |
| [17:57:37] | Mousey (Mousey!~r0dent_@ross154.net) has joined #mythtv | |
| [17:59:21] | neufeld` is now known as neufeld | |
| [17:59:22] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:4411:248b:88c1:f2fb) has quit (Read error: Connection reset by peer) | |
| [18:02:10] | danielk22: | stichnot: On the first question, I'm don't think we should be inserting seektable entries during playback at all if the recording is still in progress. |
| [18:03:10] | stichnot: | danielk22: The first question has to do with "mythcommflag --rebuild" for videos in the Video Library. I'm not sure we have any non-mpeg non-h.264 recorders. |
| [18:04:21] | kwmonro`` is now known as kwmonroe | |
| [18:04:34] | stichnot: | I would have to study the avfd code a bit more, but I think it just generates an internal seektable, and only mythcommflagplayer has code that writes seektable updates to the DB. |
| [18:04:54] | danielk22: | For the avformatdecoder seektable stuff, this is very old code so I wasn't around when it was originally written. But I can provide some insight. The recorder updates the seektable in memory much more frequently and with much less latency than it updates the seektable in the database. The frontend is also notified of these updates to the seektable, in LiveTV at least, before they make it to the database. |
| [18:06:19] | danielk22: | stichnot: It generates the internal seektable and if ahead of what we got from the recorder it updates the seektable used by the frontend for seeking. It's those updates that cause havoc if they keyframes found by avfd don't match the ones found in the recorder exactly. |
| [18:06:53] | stichnot: | good, that is what I was thinking. |
| [18:07:34] | danielk22: | Ideally the whole keyframe business would be in it's own class and that complexity could be hidden away from the playback code. |
| [18:08:16] | stichnot: | Seektable updates are done by frontend pull requests to the recorder (for in-progress and live TV), rather than pushes from the recorder, so the frontend should be in sync with the recorder when it wants to seek. |
| [18:09:03] | danielk22: | So when the user seeks we pull a range update from the backend? |
| [18:09:14] | stichnot: | yes, I believe so |
| [18:09:31] | stichnot: | it checks both the DB and the backend potentially |
| [18:10:58] | stichnot: | For my first question, can you think of a reason why we can't "reliably parse keyframes" for any codec? |
| [18:12:57] | danielk22: | It could be bugs, or limitations in the parser, or differing definitions of the 'start' of a keyframe. |
| [18:14:27] | stichnot: | Essentially, I'd like to revert https://github.com/MythTV/mythtv/commit/d4cec . . . a6d0061b69aa and clean up the rest of the livetv/watchingrecording cases, and strongly encourage users to rebuild the seektable for corrupted/legacy recordings/videos. And move like you said toward a single point of keyframe identification. |
| [18:15:06] | danielk22: | I have no problem with that. |
| [18:15:27] | stichnot: | Along those lines, I would add an explicit "Jobs" menu item to rebuild the seek table, because otherwise most users won't do it. |
| [18:15:28] | stuartm: | stichnot: how many recordings are we talking? Everything recorded before the change? |
| [18:16:57] | danielk22: | stuartm: Everything recorded should be fine I think, it's just imported and corrupted stuff that doesn't have keyframes. |
| [18:17:16] | stichnot: | stuartm: Old recordings should already have a valid seektable and no action would be necessary. This is primarily for videos, and recordings with incorrect or corrupted seektables, perhaps as a result of older mythtv bugs. |
| [18:17:42] | stuartm: | stichnot: ok that sounds a lot more reasonable than I first thought ;) |
| [18:17:49] | stichnot: | for example, until recently "mythcommflag --rebuild" over-identified keyframes for h.264 recordings |
| [18:19:12] | stichnot: | stuartm: yeah, with almost 3000 recordings and videos, I am sensitive to changes that involve reprocessing all files :) |
| [18:20:07] | stichnot: | I'll look into this avfd cleansing, but only for Master and not 0.26 |
| [18:21:14] | danielk22: | stichnot: I wonder if the mythcommflag --rebuild problem and the [d4cec14f16919] commit are related. |
| [18:24:47] | stichnot: | danielk22: the user reports that if he set can_reliably_parse_keyframes=true, it works (in the sense that seektable entries are produced, where none were before), however it may be identifying some incorrectly because he gets pixellation shortly after seeking. |
| [18:25:13] | stichnot: | which led me to "git blame" and identify that commit |
| [18:25:39] | shad0VV (shad0VV!~znc@130.43.11.219.dsl.dyn.forthnet.gr) has left #mythtv ("WeeChat 0.4.0") | |
| [18:31:01] | taylorr: | stichnot: when a seektable is present the player performs seeking by byte position, many codecs have issues doing that.. we should only only seektables for MPEG-TS and MPEG-PS videos |
| [18:34:19] | stichnot: | taylorr: I thought ffmpeg was tolerant to errors/noise in the byte position. Does this mean that some codecs have less tolerance for noise? |
| [18:35:44] | taylorr: | stichnot: at one point in time doing seeking by bytes on matroska would cause ffmpeg to hang.... but you can definitely expect corruption right after a seek for non MPEG videos |
| [18:37:18] | stichnot: | taylorr: I see, you're saying seeks are always possible but don't expect them to be "clean" for all codecs, right? |
| [18:37:49] | taylorr: | right, expect the unexpected with some codecs |
| [18:38:48] | taylorr: | the reason to only allow certain codecs to build seektables is mainly just to prevent complaints from users |
| [18:40:18] | taylorr: | in reality you should only need seektables for MPEG (TS/PS) since they support discontinuities... pretty much all other codecs don't support that so seeking by frames should be good (except being slower) |
| [18:44:37] | stichnot: | ok. Interestingly, the user gave me a sample, and seeking appears fast and accurate without a seektable, so I wonder what the issue is... |
| [18:46:04] | stichnot: | One minor issue is that the cutlist editor requires a seektable to be present, but that could probably be relaxed. |
| [18:46:44] | taylorr: | stichnot: can we do cuts for non-MPEG videos? |
| [18:48:09] | peper03 (peper03!~peper03@port-92-203-113-123.dynamic.qsc.de) has joined #mythtv | |
| [18:48:19] | stichnot: | I don't know about physical cuts via transcoding, but the player handles them fine. |
| [18:48:51] | Mousey (Mousey!~r0dent_@ross154.net) has quit (Quit: Read Error: Connection reset by beer) | |
| [18:49:38] | taylorr: | stichnot: ok, just thought I'd let you know my experiences from the past, you could spend a lot of time trying to support every container/codec with not much gain |
| [18:50:31] | stichnot: | thanks, it's all very useful to know. |
| [18:50:33] | taylorr: | I do know that the last time I looked ffplay did seeking by bytes for containers that supported discontinuities and seeking by frames for all else |
| [18:51:17] | stichnot: | Does ffplay have to do linear search for a particular frame? |
| [18:51:53] | taylorr: | I did look at one ticket that complained about corruption when seeking an AVI video with a seektable... I got the corruption to go away by modifying the byte position by 8 bytes |
| [18:52:20] | stichnot: | (and I need to learn all the distinctions between containers, codecs, etc.) |
| [18:53:10] | taylorr: | stichnot: you mean ffmpeg, I imagine it does some type of bisect algorithm to find the closest keyframe to the desired frame position |
| [18:54:46] | taylorr: | the container should report whether or not it supports discontinuities and I believe only MPEG (TS/PS) support this... look at ffplay for an example |
| [18:55:39] | taylorr: | my opinion is to look for the discontinuity flag and if it's not set then don't allow seektable creation |
| [18:56:35] | taylorr: | I doubt you'd need to look further into the container at the video codec |
| [18:59:12] | stichnot: | Is seektable/framecount information part of the container info? |
| [18:59:56] | taylorr: | stichnot: I'm not sure about the specifics of each container... I think matroska might have seektable info... not sure |
| [19:02:15] | stichnot: | I guess what I want to know is how to tell whether a video has guaranteed fast seeking (constant or log(n) time, as opposed to linear). A seektable basically gives contant time seeking. If seeking is linear, I would want to generate a seektable. |
| [19:02:33] | stichnot: | And this applies to frame-based seeking as well as time-based seeking. |
| [19:06:37] | taylorr: | stichnot: sorry, no idea about that stuff |
| [19:07:07] | stichnot: | I guess that would mean studying the ffmpeg code... |
| [19:14:06] | taylorr: | stichnot: I understand the desire to support all this but keep in mind that no other player can do this on the planet that I'm aware of |
| [19:16:28] | taylorr: | another reason to not support some of this is that ffmpeg is not developed to support this... it would be interesting how an ffmpeg ticket would be handled concerning byte-based seeking for a non-MPEG (TS/PS) container |
| [19:17:10] | taylorr: | of course I could be totally wrong and all the containers should properly support byte-based seeking... that would be great |
| [19:41:00] | stichnot: | I definitely want to clean up the unnecessary distinctions between in-progress and pre-recorded. I'll do some more digging into when seektables are really needed before going further in that direction. |
| [19:43:28] | taylorr: | stichnot: you could always post these questions to the ffmpeg-users/libav-users mailing list and you'd probably get much better answers than I can provide :) |
| [19:47:14] | stichnot: | ok, that's a good idea |
| [21:25:08] | wilmoore-misc (wilmoore-misc!~wilmoore@vlandnat.mystrotv.com) has quit (Ping timeout: 272 seconds) | |
| [21:25:29] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Read error: Connection reset by peer) | |
| [21:26:55] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [21:42:52] | wilmoore-misc (wilmoore-misc!~wilmoore@vlandnat.mystrotv.com) has joined #mythtv | |
| [21:42:56] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [21:52:27] | skd5aner (skd5aner!~skd5aner@50-90-30-141.res.bhn.net) has joined #mythtv | |
| [22:44:47] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 260 seconds) | |
| [22:59:45] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [23:02:21] | stichnot: | skd5aner: I haven't tried exhaustively, but I and another user seem to be unable to reproduce #11159, me in Master and him in 0.26. Are you able to reproduce it with a recent unpatched master or 0.26? |
| [23:02:21] | ** MythLogBot http://code.mythtv.org/trac/ticket/11159 ** | |
| [23:03:09] | skd5aner: | stichnot: I havne't tried since jya's original patch was reverted... |
| [23:03:14] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [23:03:37] | skd5aner: | It worked for me that way, so I haven't been anxious to update... I can try sometime tomorrow likely and report back with a fresh checkout of -fixes |
| [23:03:41] | jpabq: | stichnot, neufeld: If you care to try it: http://code.mythtv.org/trac/attachment/ticket . . . ame-v3.patch |
| [23:05:07] | jpabq: | stichnot: Even with this, the distance between the first and second keyframes is less than normal. That just seems to be the way the HD-PVR starts out a new recording. If you have back-to-back recordings, the second recording will start out with the 128 distance, since the HD-PVR is never told to stop/start in that situation. |
| [23:08:12] | stichnot: | jpabq: I'll give it a try. My main goal/preference is that the recorder, mythcommflag --rebuild, and mythtranscode --buildindex are all in agreement. Second goal is that they are actually correct. :) |
| [23:08:40] | stichnot: | skd5aner: that would be great, thanks. I'm wondering if some other commit accidentally fixed the problem. |
| [23:09:10] | skd5aner: | stichnot: it's super easy for me to replicate – do you have the test file I uploded to the box account? |
| [23:09:55] | stichnot: | I don't have it handy, but the other user I mentioned does (I think) and couldn't reproduce it. |
| [23:11:21] | jpabq: | This should not cause any problems with mythcommflag. Basically, when parsing a "payload", we may not know if it is a keyframe until several "packets" have been read. With the old code, we would throw away all the previous packets, and start writing to disk with *the* packet that finally let us know it was a keyframe. With the patch, we preserve all the packets beginning with the payload start. |
| [23:12:06] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [23:12:18] | jpabq: | Actually, I guess mythcommflag could have the same problem — marking the offset as being the location of the packet that tells us it's a keyframe, instead of the packet that starts the payload. |
| [23:14:31] | stichnot: | I think the current problem is that mythcommflag and the recorder don't agree on the frame numbers of the keyframes. The file offsets are within epsilon, but the frame numbers are off. |
| [23:14:58] | stichnot: | Earlier there was a problem that mythcommflag would also mark the non-IDR keyframes, but that has been fixed. |
| [23:19:08] | peper03 (peper03!~peper03@port-92-203-113-123.dynamic.qsc.de) has quit (Read error: Connection reset by peer) | |
| [23:19:33] | jpabq: | Speaking of mythcommflag, I did try the last couple of patches on #10793. While they did change the behavior a little bit, over all I really don't see a difference in the accuracy. |
| [23:19:33] | ** MythLogBot http://code.mythtv.org/trac/ticket/10793 ** | |
| [23:20:00] | jpabq: | I need to try Mark's patches next. |
| [23:35:34] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [23:43:01] | stichnot: | jpabq: wow, using your patch, 2 test hdpvr recordings (not back-to-back) have exactly the same seektable before and after mythcommflag --rebuild |
| [23:43:27] | jpabq: | stichnot: in mythcommflagplayer.cpp, shouldn't it say "No IDR-frames found, rewinding...", instead of "No I-frames found, rewinding..."" |
| [23:44:04] | jpabq: | stichnot: That is an improvement, I assume? |
| [23:44:21] | jpabq: | I can't remember the last time I ran mythcommflag --rebuild |
| [23:44:28] | stichnot: | jpabq: yes, even the file offsets are exactly the same |
| [23:44:49] | stichnot: | with an hdhr, iirc, the file offsets may be 188 bytes apart |
| [23:45:21] | jpabq: | I tweaked how mpeg2 is handled as well.. |
| [23:45:28] | stichnot: | ok |
| [23:46:06] | jpabq: | Okay, well with that knowledge, I will not bother to look at the mythcommflag code at this time. |
| [23:46:31] | jpabq: | stichnot: that is a nice validation that my changes are correct — I think. |
| [23:47:02] | stichnot: | jpabq: totally. My first assumption when I did the diff was that I screwed up the test :) |
| [23:47:47] | stichnot: | I need to repeat the test with back-to-back recordings. The scheduler keeps insisting on putting the second recording on the PVR-150 :) |
| [23:48:52] | jpabq: | You probably have "Avoid back to back recordings" set to Always. |
| [23:49:50] | stichnot: | Most likely. I'll just temporarily disable the PVR-150, which is included as a recorder only for investigating the PVR-150 live TV problems. |
| [23:50:02] | jpabq: | gigem has talked about removing that setting, and just making "Always" the way it works. |
| [23:50:47] | jpabq: | You could also put the HD-PVR and the PVR-150 in the same group. That should tell Myth they can't be used at the same time. |
| [23:51:49] | jpabq: | Actually, if you could test the patch with the PVR-150, that would be good. I don't have any easy way to do that... |
| [23:52:39] | jpabq: | I do have a PVR-500, but I haven't used it to record in years. |
| [23:52:49] | stichnot: | I can test that. |
| [23:53:16] | stichnot: | I expect that putting the tuners in an input group wouldn't change anything. After all, I'm not actually trying to record at the same time. |
| [23:55:56] | stichnot: | The real use now for the PVR-150 is to get SRT captions for the HD-PVR recordings. |
| [23:56:09] | stichnot: | I guess you're using your PVR-500 for that? |
| [23:56:39] | jpabq: | Yes. Myth knows nothing about it. I use it's two inputs to get CC for my two HD-PVRs. |
| [23:57:40] | jpabq: | I believe that when the HVR-2250 is used in analog mode, with the latest driver, that a vbi device is created. I wonder if it could be used for that purpose? |
| [23:58:38] | stichnot: | It would be cool to integrate that into the recorder infrastructure, but it's hard to justify such a niche feature. |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.