| Monday, September 30th, 2013, 00:01 UTC | ||
| [00:01:23] | kenni (kenni!~kenni@mythtv/developer/kenni) has quit (Ping timeout: 245 seconds) | |
| [00:02:52] | dekarl (dekarl!~dekarl@p4FE84685.dip0.t-ipconnect.de) has joined #mythtv | |
| [00:04:43] | dekarl1 (dekarl1!~dekarl@p4FCEF709.dip0.t-ipconnect.de) has quit (Ping timeout: 248 seconds) | |
| [00:14:43] | drrngrvy (drrngrvy!~darren.ga@cpc23-cmbg14-2-0-cust103.5-4.cable.virginmedia.com) has quit (Ping timeout: 245 seconds) | |
| [00:51:48] | jya_: | is there a way to run myth without X on linux ? using directly video output? |
| [00:52:41] | wagnerrp: | i believe support for that left with the PVR-350 |
| [00:53:13] | jya_: | seems that X on the raspberry pi doesn't support OpenGL at all, only way I can get some opengles app to run is directly tapping into the hardware |
| [00:53:54] | jya_: | examples from there: http://benosteen.wordpress.com/2012/04/27/usi . . . t-x-windows/ |
| [00:54:20] | jya_: | wagnerrp: what's the pvr-350? |
| [00:54:47] | wagnerrp: | an old hauppauge tuner card with an onboard MPEG2 decoder and video output |
| [00:55:18] | jya_: | why would myth not require X for that one ? |
| [00:55:36] | jya_: | that's how xvmc manages to run OpenGL es on the pi, without X ... |
| [00:56:23] | wagnerrp: | you couldn't use X if you wanted hardware decoding |
| [00:56:30] | jya_: | seems this is opening a can of worms... i thought it was just a matter of getting OpenGL es compiled for the pi with qt5... after a full day I reach that point, another day to compile myth, and it doesn't even start when compiled with OpenGL es |
| [00:56:36] | wagnerrp: | you had to push the video directly to the device, and use a framebuffer for everything else |
| [00:57:40] | jya_: | with Qt painter, i managed to start the fronted, and I easily get something like... oh, easily... 1 frame every 4–5s |
| [00:57:46] | wagnerrp: | i believe support for it, and any other framebuffer output, was removed for 0.22 |
| [01:00:34] | jya_: | hm.... just installed xbmc, it's surprisingy responsive ! |
| [01:07:13] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Quit: Konversation terminated!) | |
| [01:09:05] | jya_: | ohhhh... it even works with the projector remote control... |
| [01:12:05] | jya_: | they've done a great job really... |
| [01:12:21] | ** jya_ why do we bother with a frontend ... ** | |
| [01:31:43] | shodan45 (shodan45!~chris@71-15-44-176.dhcp.thbd.la.charter.com) has joined #mythtv | |
| [01:32:15] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv | |
| [01:45:22] | kenni (kenni!~kenni@mythtv/developer/kenni) has joined #mythtv | |
| [01:48:59] | jya_: | well, looks like if we ever want myth to run on embedded platform, the first step is to (re)add support for drawing directly into a framebuffer |
| [01:56:24] | thatswork (thatswork!thatswork@c-107-2-77-70.hsd1.mn.comcast.net) has joined #mythtv | |
| [02:18:48] | _nyloc_ (_nyloc_!~quassel@p3EE2D7E0.dip0.t-ipconnect.de) has joined #mythtv | |
| [02:19:50] | nyloc (nyloc!~quassel@p3EE2C60B.dip0.t-ipconnect.de) has quit (Read error: Operation timed out) | |
| [02:41:06] | thatswork (thatswork!thatswork@c-107-2-77-70.hsd1.mn.comcast.net) has quit () | |
| [02:49:36] | joki- (joki-!~joki@p5486382C.dip0.t-ipconnect.de) has quit (Ping timeout: 245 seconds) | |
| [02:50:25] | robink (robink!~quassel@unaffilated/robink) has quit (Ping timeout: 245 seconds) | |
| [02:54:56] | joki (joki!~joki@p548614FC.dip0.t-ipconnect.de) has joined #mythtv | |
| [02:58:35] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 248 seconds) | |
| [03:00:05] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [04:01:40] | fetzerch_ (fetzerch_!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 264 seconds) | |
| [04:03:11] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:43:12] | sl1ce_1g (sl1ce_1g!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv | |
| [04:44:01] | Gibby (Gibby!~Gibby@mylanupdates.eclipse.25u.com) has joined #mythtv | |
| [04:44:37] | jwhite_ (jwhite_!~jwhite@75-146-153-89-minnesota.hfc.comcastbusiness.net) has joined #mythtv | |
| [04:44:49] | aloril_ (aloril_!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has joined #mythtv | |
| [04:45:58] | seld_ (seld_!~seld@h7n7-rny-a12.ias.bredband.telia.com) has joined #mythtv | |
| [04:49:36] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (*.net *.split) | |
| [04:49:36] | Gibby_ (Gibby_!~Gibby@mylanupdates.eclipse.25u.com) has quit (*.net *.split) | |
| [04:49:36] | XDS2010_ (XDS2010_!uid1218@gateway/web/irccloud.com/x-ciryuqsyrofncwfn) has quit (*.net *.split) | |
| [04:49:36] | jwhite (jwhite!~jwhite@75-146-153-89-minnesota.hfc.comcastbusiness.net) has quit (*.net *.split) | |
| [04:49:37] | seld (seld!~seld@h7n7-rny-a12.ias.bredband.telia.com) has quit (*.net *.split) | |
| [04:49:37] | aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has quit (*.net *.split) | |
| [04:49:45] | XDS2010__ (XDS2010__!uid1218@gateway/web/irccloud.com/x-jvmcbnknsucemvdp) has joined #mythtv | |
| [05:47:08] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [06:02:59] | SteveGoodey (SteveGoodey!~steve@host86-132-98-69.range86-132.btcentralplus.com) has joined #mythtv | |
| [06:12:05] | SteveGoodey (SteveGoodey!~steve@host86-132-98-69.range86-132.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [06:13:50] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [06:14:52] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [06:15:09] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 252 seconds) | |
| [06:28:16] | XDS2010__ is now known as XDS2010 | |
| [07:22:42] | robink (robink!~quassel@unaffilated/robink) has joined #mythtv | |
| [07:30:14] | doev (doev!~doev@p4FD42BA6.dip0.t-ipconnect.de) has joined #mythtv | |
| [08:01:55] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:c85a:e665:99e3:7e42) has joined #mythtv | |
| [09:10:23] | cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has quit (Ping timeout: 260 seconds) | |
| [09:10:28] | cecil (cecil!~cesman@pool-108-23-186-67.lsanca.fios.verizon.net) has joined #mythtv | |
| [09:21:01] | FabriceMG1 (FabriceMG1!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [09:24:23] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Ping timeout: 260 seconds) | |
| [09:25:19] | FabriceMG1 (FabriceMG1!~Thunderbi@217.112.59.207) has quit (Ping timeout: 260 seconds) | |
| [09:40:44] | MythBuild: | build #4479 of master-freebsd-64bit is complete: Failure [4failed compile plugins] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/4479 blamelist: Stuart Morgan <smorgan@mythtv.org > |
| [09:40:54] | MythBuild: | build #687 of master-linux-64bit-qt5 is complete: Failure [4failed compile plugins] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . 5/builds/687 blamelist: Stuart Morgan <smorgan@mythtv.org > |
| [09:46:46] | MythBuild: | build #176 of master-f19–32bit is complete: Failure [4failed compile plugins] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/176 blamelist: Stuart Morgan <smorgan@mythtv.org > |
| [09:48:54] | MythBuild: | build #1071 of master-ubuntu-12_04-lts-64bit is complete: Failure [4failed compile plugins] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1071 blamelist: Stuart Morgan <smorgan@mythtv.org > |
| [09:50:52] | MythBuild: | build #1057 of master-f18–64bit is complete: Failure [4failed compile plugins] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1057 blamelist: Stuart Morgan <smorgan@mythtv.org > |
| [09:51:13] | MythBuild: | build #334 of master-f19–64bit is complete: Failure [4failed compile plugins] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/334 blamelist: Stuart Morgan <smorgan@mythtv.org > |
| [09:51:42] | MythBuild: | build #1603 of master-linux-64bit-icc is complete: Failure [4failed compile plugins] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1603 blamelist: Stuart Morgan <smorgan@mythtv.org > |
| [09:52:00] | MythBuild: | build #1374 of master-debian-wheezy-64bit is complete: Failure [4failed compile plugins] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1374 blamelist: Stuart Morgan <smorgan@mythtv.org > |
| [09:53:20] | stuarta: | ooo errr... |
| [09:54:01] | MythBuild: | build #1247 of master-linux-64bit-clang is complete: Failure [4failed compile plugins] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1247 blamelist: Stuart Morgan <smorgan@mythtv.org > |
| [09:54:37] | MythBuild: | build #1064 of master-ubuntu-12_10–64bit is complete: Failure [4failed compile plugins] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1064 blamelist: Stuart Morgan <smorgan@mythtv.org > |
| [09:55:30] | stuartm: | damn it |
| [09:56:56] | Guest59384 (Guest59384!~neon@bzq-79-176-185-144.red.bezeqint.net) has quit (Ping timeout: 256 seconds) | |
| [09:57:57] | Guest59384 (Guest59384!~neon@bzq-79-176-185-144.red.bezeqint.net) has joined #mythtv | |
| [10:05:05] | drrngrvy (drrngrvy!~darren.ga@31.221.37.8) has joined #mythtv | |
| [10:05:39] | jya_: | stuartm: is there anything in our code that fundamentally require X11 to run, or if I managed to get Qt to be compiled to run directly against a frame buffer and using that Qt then myth would directly work with it ? |
| [10:06:14] | MythBuild: | build #688 of master-linux-64bit-qt5 is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . 5/builds/688 |
| [10:06:36] | MythBuild: | build #4480 of master-freebsd-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/4480 |
| [10:07:28] | stuartm: | jya_: not entirely sure, I know X11 is used for device input (keyboard etc) but I don't know whether QT will handle that another way if it's compiled without X11 support |
| [10:07:57] | jya_: | don't we get the mouse and keyboard event through Qt directly? |
| [10:08:09] | stuartm: | no, in linux it all goes through X11 |
| [10:08:50] | jya_: | sorry, maybe I don't make myself clear... I thought the mouse event and keyboard events were received in myth via Qt event loop ... |
| [10:09:07] | jya_: | how Qt managed to get those, is its problem I guess... |
| [10:10:07] | stuartm: | yes, and those events when compiled with X11 are XEvents received by QT, I honestly don't know how that would work without X11 – but as you say that's all down to QT |
| [10:11:08] | stuartm: | there are some parts of the code which make direct X calls, to determine stuff like xinerama screens, screensaver support |
| [10:12:50] | stuartm: | I don't think it would be as simple as just recompiling without X11, you'd need to add few ifdefs to use the FB specfic parts of QT – just as we do now for OSX/Windows |
| [10:14:02] | MythBuild: | build #177 of master-f19–32bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/177 |
| [10:15:02] | MythBuild: | build #1072 of master-ubuntu-12_04-lts-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1072 |
| [10:16:54] | Guest59384 (Guest59384!~neon@bzq-79-176-185-144.red.bezeqint.net) has quit (Ping timeout: 264 seconds) | |
| [10:17:24] | MythBuild: | build #1058 of master-f18–64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1058 |
| [10:17:47] | stuartm: | looks like some of that code could now be replaced by QT5 code – e.g. DisplayRes() by QT5's QScreen? |
| [10:18:12] | MythBuild: | build #335 of master-f19–64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/335 |
| [10:18:35] | MythBuild: | build #1375 of master-debian-wheezy-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1375 |
| [10:19:05] | Guest59384 (Guest59384!~neon@bzq-79-176-185-144.red.bezeqint.net) has joined #mythtv | |
| [10:19:13] | stuartm: | jya_: is this something to do with running the frontend on the RPi? |
| [10:19:20] | jya_: | yes... |
| [10:20:33] | jya_: | stuartm: in regards to the stuff like finding out the screen resolutions, the number of screens etc... There's an API for that on the pi: OpenMax AL... That shouldn't be too much of a problem to get going. |
| [10:21:12] | MythBuild: | build #1065 of master-ubuntu-12_10–64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1065 |
| [10:21:14] | MythBuild: | build #1604 of master-linux-64bit-icc is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1604 |
| [10:21:27] | jya_: | could even write a native openmax AL audio interface, so you can detect things without alsa or pulse... much less CPU intensive. it also provides basic functionality to hardware decode things like mp3 |
| [10:21:31] | MythBuild: | build #1248 of master-linux-64bit-clang is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1248 |
| [10:21:43] | stuartm: | jya_: you might try asking Mark K, fairly certain he'll know more than I do on the subject of ES and framebuffer output |
| [10:22:05] | stuartm: | jya_: sounds good |
| [10:22:26] | jya_: | yeah, I read about how he got ES running, he was using a tegra board and simulator... I have downloaded those already to play |
| [10:23:00] | jya_: | but to be honest, I think it would probably be less effort to improve the myth xbmc plugin than having a native myth frontend. |
| [10:23:57] | jya_: | i had a play with it, the features are there, but it's not very friendly.. it takes forever to retrieve the list of recordings (it get the whole list of all recordings and sort it before you can do anything with the myth plugins) |
| [10:24:22] | jya_: | also live TV, changing channels take like 30+s... and when you're changing channel you have no idea about what it's doing |
| [10:24:39] | jya_: | but UI wise, it's all there.... and it uses a tiny amount of RAM (about 25MB) |
| [10:24:56] | stuartm: | personally I'd rather have choice, and since I've spent years working on the UI and other frontend specific enhancements, hearing people proposing that we drop the frontend is a knife to the heart :) |
| [10:25:01] | jya_: | just starting mythfrontend and it's already in the vicinity of 200MB without doing anything |
| [10:25:30] | jya_: | stuartm: oh, I feel the same ... |
| [10:25:47] | stuartm: | jya_: not saying we can't improve, it just takes some effort |
| [10:25:51] | jya_: | 95% of my involvement in myth has been fronted related |
| [10:26:46] | jya_: | but I just see how responsive and usable their UI is on a 700MHz machine... I'm not sure we can get there with what we have now |
| [10:26:50] | stuartm: | we need to get rid of the legacy code, legacy hardware support then focus on the performance improvements |
| [10:27:21] | jya_: | not sure this has any consequences on the performance to be honest. |
| [10:27:27] | stuartm: | I'd like to know how xbmc can present a blindingly fast UI without apparently doing any image caching (at least not in system memory) |
| [10:27:43] | jya_: | like I'm glad we had the Qt painter... otherwise I would have had no UI at all on the pi |
| [10:27:51] | jya_: | X11 on the pi doesn't support opengl |
| [10:28:12] | jya_: | they say it's temporary, but they've been saying so for 1 year |
| [10:28:55] | jya_: | on the other hand, I'm very excited with the idea of a frontend that fit in a pi... |
| [10:29:23] | jya_: | I see a way to actually start an appliance business there... sell usable solution on top of providing open source code |
| [10:30:29] | stuartm: | jya_: quite a lot of that memory usage will be texture/image caches, some of which is probably overkill – I was all set to slash the size of the string texture cache until it was pointed out that the re-written scrolling text code created a new texture for each pixel position :( |
| [10:31:05] | jya_: | is that what stichnot removed ? |
| [10:31:24] | jya_: | i read on the theme mailing list, that images are always scaled twice. |
| [10:31:25] | stuartm: | although thinking about it, it's probably unable to use the cache at all because it will quickly push out textures |
| [10:31:35] | stuartm: | jya_: that's now fixed |
| [10:31:44] | jya_: | in 0.27 or just master? |
| [10:31:49] | stuartm: | the double scaling, pushed a fix last night to master |
| [10:32:09] | stuartm: | jya_: master for now, want to see if we get any reports of breakage |
| [10:33:06] | jya_: | i told you that when you move the cursor in the myth video folder, the image placeholder get refreshed each time (so if you have 40 icons, with 10 icons not having fan art, only showing the placeholder, those 10 icons blink and are fully redrawn each time. |
| [10:34:39] | jya_: | there's another issue I discussed on the theme list, if the list of files isn't fully filling the screen, then moving the cursor at the edge of the screen has some very weird and unexpected behaviour... like going left, and the cursor goes diagonally ... things like that |
| [10:36:50] | stuartm: | jya_: I need to look into those |
| [10:38:50] | jya_: | stichnot: i was reading today about a compatibility issue with xbmc issues using myth bookmarks and ad detection.. one of the comment was due to xbmc using time stamps, actually based on time, vs myth using frame count as timestamp |
| [10:39:28] | jya_: | seeing your last commit to fix some avi files, wouldn't it be easier to actually stop using frame count as timestamp, and use proper timing value ? |
| [10:40:22] | jya_: | with that, you can use FFmpeg everywhere to seek... the framerate become irrelevant (FFmpeg properly handle seeking in those) |
| [10:44:53] | caelor (caelor!~quassel@cpc12-sotn9-2-0-cust374.15-1.cable.virginmedia.com) has quit (Ping timeout: 248 seconds) | |
| [10:45:31] | PatrickDickey (PatrickDickey!~quassel@2001:470:1f11:830:78b1:a68d:f5f5:ea68) has quit (Read error: Connection reset by peer) | |
| [10:47:10] | stuartm: | if I change the existing hard-coded caches to use a percentage of system memory, what should that percentage be? |
| [10:47:51] | stuartm: | what's 'reasonable'? |
| [10:49:31] | stuartm: | 3%? |
| [10:50:17] | jya_: | re the cursor moving in a weird fashion: #11790 |
| [10:50:17] | ** MythLogBot http://code.mythtv.org/trac/ticket/11790 ** | |
| [10:50:25] | jya_: | hmmm..... that sounds very little |
| [10:50:35] | jya_: | can you make it a % of the free memory? |
| [10:50:40] | jya_: | then... 50% ? :) |
| [10:51:21] | jya_: | or more even |
| [10:53:59] | stuartm: | free memory will vary over time, that would involve continually re-checking how much space we're allowed to use – not impossible just different from the constants we're using now |
| [10:54:13] | stuartm: | but maybe it's a better approach |
| [10:54:49] | stuartm: | fwiw, 3% was dumb, I based that on my own system without really considering how little that would actually be for machines with less RAM available :) |
| [10:55:54] | stuartm: | on 256MB, 3% wouldn't even be enough for one, fullscreen image (1920x1080) |
| [10:56:36] | dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip.81.200.198.20) has joined #mythtv | |
| [10:56:58] | stuartm: | there probably needs to be some min/max caps, not everyone will be so understanding if mythfrontend is using 4GB of memory! |
| [10:57:00] | caelor (caelor!~quassel@cpc12-sotn9-2-0-cust374.15-1.cable.virginmedia.com) has joined #mythtv | |
| [10:57:24] | jya_: | stuartm: the pi with openmax has hardware accelerated image decoding (jpeg/png) and scaling.... if we were to use this, caching would probably not help much |
| [10:58:19] | jya_: | adding openmax support would actually open a fair amount of embedded platforms... there's a few tiny boards out there with openmax and OpenGL es support |
| [10:58:24] | jya_: | including android |
| [10:58:25] | dekarl-work: | stuartm: I'd try to avoid a big cache for big art images. better convert them to a hardware readable format and stream them from the buffer cache directly to the gpu memory. |
| [10:59:18] | dekarl-work: | so if you want to invest time into thinking / coding its likely better invested in caches for dynamic images. |
| [10:59:38] | jya_: | dekarl: and seeing how slow the SD card access is from a pi, reading a fully decoded and scaled image, is probably not much faster than reading a much smaller compressed file |
| [10:59:44] | dekarl-work: | but even those will be shrinking if we can move more stuff to shaders / the gpu in general |
| [11:00:09] | stuartm: | dekarl-work: right now I'm not proposing re-writing the way the cache works |
| [11:00:34] | dekarl-work: | jya_: for the PI I would expect it to stream from the backends buffer cache into the PIs GPU memory with as little in between as we can |
| [11:01:21] | dekarl-work: | stuartm: I know. I'm just trying to suggest not to invest to much effort into stuff that should go away if we go for a full OpenGL enabled rendering. |
| [11:01:36] | dekarl-work: | s/OpenGL/GPU accelerated/ |
| [11:01:38] | stuartm: | we could store an uncompressed image on disk instead of a png, but that would massively increase the size of the themecache – mine was already huge, so we'd need to implement a housekeeper task to clear up that cache periodically |
| [11:02:31] | stuartm: | well we already need a housekeeper task, it would just become more urgent |
| [11:02:32] | dekarl-work: | I was thinking about storing files in DDS format with precomputed mipmaps... Just load the texture as big as we need it and push it directly to the gpu. |
| [11:03:42] | dekarl-work: | but I was thinking on waiting until the schema change is in so we can track multiple encodings of the same video/recording/poster |
| [11:04:42] | stuartm: | dekarl-work: we do a lot of waiting for other changes to happen first :/ |
| [11:04:59] | dekarl-work: | aye :) |
| [11:05:42] | dekarl-work: | maybe we could try to come up with some kind of plan. do we want to finish the move to hardware accelerated gui? |
| [11:07:22] | stuartm: | is anyone going to miss the on-screen keyboard if we lose it for the old QT based settings? I'd like if possible to jettison it now, and maybe not even bring it back – 99% of settings currently using it could/should probably use a file browser or select box instead |
| [11:07:53] | stuartm: | and to maintain the old keyboard (distinct from the new mythui one) requires hanging on to a fair bit of legacy code |
| [11:09:05] | stuartm: | no-one? OK, can't say I didn't ask first :) |
| [11:12:10] | dekarl-work: | one OSK has to be enough for everyone ;) |
| [11:53:46] | doev (doev!~doev@p4FD42BA6.dip0.t-ipconnect.de) has quit (Ping timeout: 245 seconds) | |
| [11:54:31] | doev (doev!~doev@p4FD415E3.dip0.t-ipconnect.de) has joined #mythtv | |
| [12:02:08] | cecil_ (cecil_!~cesman@pool-108-23-186-67.lsanca.fios.verizon.net) has joined #mythtv | |
| [12:02:13] | cecil (cecil!~cesman@pool-108-23-186-67.lsanca.fios.verizon.net) has quit (Ping timeout: 245 seconds) | |
| [12:05:58] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 245 seconds) | |
| [12:07:16] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [12:29:46] | jya_: | ohhhhh.... i have my qt app running without X11 and straight into the frame buffer |
| [12:31:49] | jya_: | stuartm: I simply forced Qt to use a single EGL surface as QWindow... everything then worked; including the mouse |
| [12:31:58] | stuartm: | seems like we might be able to use http://qt-project.org/doc/qt-5.1/qtwidgets/qdesktopwidget.html to get the display information for QT4.8 |
| [12:32:20] | stuartm: | jya_: this is a test app you wrote, or mythfrontend? |
| [12:32:37] | jya_: | it's the sample cube app in the qt5 examples |
| [12:33:39] | jya_: | now the problem is to start the qt app in this environment, you provide it with arguments that qt will handle automatically, with mythfrontend however, that doesn't work as it parses all arguments itself |
| [12:40:48] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 240 seconds) | |
| [12:41:55] | stuartm: | it should be possible to pass those directly internally? |
| [12:43:04] | jya_: | it depends of the arguments provided to the QApplication constructor |
| [12:44:03] | jya_: | problem is MythFrontendCommandLineParser returns an error before the QApplication is created |
| [12:49:41] | stuartm: | jya_: I meant, it should be possible to instead invoke some QT api to do the same thing? |
| [12:50:03] | stuartm: | maybe not so straightforward for testing purposes though |
| [12:50:10] | jya_: | probably... I'm looking :) |
| [12:50:29] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [12:50:32] | stuartm: | sounds like the sort of thing they'd use a define or env variable for |
| [12:50:56] | jya_: | the whole detection on opengles vs OpenGL doesn't work with qt5... the enable_opengles that is used in libmythui.pro doesn't seem to be set |
| [12:51:53] | jya_: | same in the configure... the check using pkg-config about which OpenGL was used within qt doesn't work |
| [12:57:55] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [12:59:38] | stichnot: | stuartm: I sometimes use the on-screen keyboard for incremental search in a large list of recordings |
| [13:01:10] | stuartm: | stichnot: different on-screen keyboard |
| [13:01:16] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 245 seconds) | |
| [13:01:44] | stichnot: | oh, then I'm not sure which keyboard you're talking about |
| [13:01:50] | stuartm: | this is the old qt based one which is only used for text-entry settings in the old (non mythui) settings screens |
| [13:02:06] | stuartm: | looks identical, but uses entirely different code |
| [13:02:08] | stichnot: | ah |
| [13:02:34] | stuarta: | we need to take the highlander approach "there shall be only *one*" (unless of course you need a sequel) |
| [13:02:44] | stichnot: | OK, I'll have a look. |
| [13:02:53] | stuartm: | I've already removed it locally, just compile testing |
| [13:02:55] | stuartm: | 17 files changed, 11 insertions(+), 3508 deletions(-) |
| [13:03:27] | stichnot: | In the backend setup, there are sometimes things like entering scripts, though that's painful enough that it's a lot better to do it where you have an actual keyboard |
| [13:04:18] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [13:04:52] | stuartm: | stichnot: right, those should have used a file browser, not a text entry |
| [13:05:18] | stichnot: | not just the file path, but the args as well |
| [13:05:35] | stichnot: | like system events |
| [13:05:58] | stuartm: | since I'll be converting mythtv-setup to use mythui entirely by the next release it's a moot point |
| [13:06:27] | stichnot: | jya_: I don't think I did anything with image caching, maybe you're thinking of how I changed the way text outlines are drawn? |
| [13:07:10] | stichnot: | jya_: I've been thinking the same thing about changing myth to be timecode based instead of frame based |
| [13:07:11] | jya_: | i mean I thought your changes exposed an issue in the way text was drawn |
| [13:07:16] | stuartm: | the only other place that's affected are the frontend settings, if we can't eliminate the text-entry stuff there entirely then I'll figure out a way to render the mythui keyboard over the QT screen |
| [13:08:01] | jya_: | stichnot: problem with frames is that the referential can change as the duration of a frame vary... at least with timestamp, it doesn't. |
| [13:08:01] | stichnot: | stuartm: could you get even more deleted code by converting settings to MythUI? :) |
| [13:08:12] | stuartm: | jya_: I think it was jpabq's change to use QTextLayout that originally introduced the issue with scrolling text |
| [13:08:23] | stuartm: | stichnot: heaps :) |
| [13:09:04] | jya_: | stuartm: the remote stuff via the service api doesn't work to enter text in the old setting screen |
| [13:09:13] | stichnot: | jya_: I can't remember any more about text issues, but you could be right :) |
| [13:09:16] | stuartm: | but it's not quite that simple, the reason we didn't do it years ago was that we didn't want to force themers to theme every single settings screen (it would be unmaintainable that way anyhow) |
| [13:09:56] | jya_: | stuartm: what about providing a simple setting container and have *all* settings rely on that. |
| [13:10:12] | stuartm: | someone wrote a patch to convert the settings to mythui using a novel 'tree' design, but it's already bitrotted pretty badly and they've not been around to update it against master |
| [13:10:15] | jya_: | looking at the settings in xbmc, it's all super consistent across the board, including the plugin settings |
| [13:10:59] | jya_: | so no fancy "I try to fit as many settings I can within the width of the screen". |
| [13:11:11] | jya_: | instead it's all one line, one setting, in a scroll list |
| [13:11:26] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 240 seconds) | |
| [13:11:43] | stuartm: | jya_: you're talking about xbmc? That's exactly what these patches in trac do (if they could be made to apply) |
| [13:12:06] | jya_: | stuartm: you could check either android settings definition or iOS system settings definition: bot is just a plain html, it provides base entry type and it all look quite nice |
| [13:12:52] | jya_: | that's how the android settings xml work... it's a tree, you have check, radio, string, number, ip address stuff like that |
| [13:13:27] | jya_: | http://developer.android.com/guide/topics/ui/settings.html |
| [13:14:04] | jya_: | it's very simple to use, allow everything, is consistent is imho much easier to read... also compatible with all screen type |
| [13:14:11] | stuartm: | yeah, would be very similar to how that works, I had one or two conceptual issues with the approach but I still intended to commit it if I could have got other devs to look at it and agree first (when I asked no-one even responded) |
| [13:14:12] | jya_: | that's the one thing I like in android.. |
| [13:15:03] | stichnot: | jya_: Two problems with timecodes. First, we see recordings where timestamps are inconsistent and lie, such as when the broadcaster stupidly splices in ads without fixing timecodes. But myth's seektables can solve that. (I don't know if changing framerates are a problem with ffmpeg, but seektables also deal with that.) Second, frame-based editing could be tricky. |
| [13:15:07] | jya_: | iOS one is even easier, but it's not as flexible |
| [13:15:43] | jya_: | stichnot: ffmpeg seek is always done by position in the stream in "bytes" |
| [13:16:14] | stichnot: | Third (did I say only two problems?), we have to keep frame-based metadata support around for eternity for legacy reasons |
| [13:16:39] | stichnot: | jya_: ffmpeg seek has two options: byte seek, or timecode seek |
| [13:17:07] | jya_: | doing a simple time * average_byterate" works well... the more accurate your calculation , the quicker the seek, but even if you provide a crap bytes, so long as the seek in ms is valid it will find it, it does a dichotomy looking at the pts/dts until it find the position you seek for |
| [13:17:15] | jya_: | the position in byte, is just a helper |
| [13:20:37] | stichnot: | jya_: you're talking about AVSEEK_FLAG_BYTE versus AVSEEK_FLAG_FRAME versus neither flag, right? |
| [13:21:58] | MythBuild: | build #72 of master-win8-msvc-2010–32bit is complete: Failure [4failed Configure and Build] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . it/builds/72 blamelist: Stuart Morgan <smorgan@mythtv.org > |
| [13:21:59] | jya_: | i'm referring to the av_seek etc... routine myth provides to ffmpeg, they seek in bytes always |
| [13:22:45] | jya_: | it's not an official API either, we're not supposed to use it |
| [13:23:37] | stuartm: | dblain: is the windows builder doing a distclean or fully clean build? |
| [13:24:26] | stuarta: | stuartm: we all agree that the current mythtv-setup sucks, so any improvements are welcome |
| [13:24:32] | stuartm: | dblain: it's failing because it's trying to build a file that no longer exists (it's not used or referenced in any of the pro files) |
| [13:25:22] | stichnot: | jya_: avformatdecoder.cpp calls av_seek_frame which includes the seeking mode flags – is that not an official API? |
| [13:26:52] | stuartm: | superm1: I vaguely recall that Xavier was an acquaintance of yours, am I right? |
| [13:27:14] | superm1: | stuartm: um if so i don't recall them |
| [13:27:34] | jya_: | stichnot: no, I'm referring to the underlying way we handle our buffer |
| [13:28:10] | stuartm: | superm1: OK, know that he was a friend or something of _someone_ in here :) |
| [13:29:05] | stuartm: | someone who has contributed to MythTV in the past but who isn't a core (code) developer |
| [13:29:57] | stuartm: | Xaveir Hervy is the guy who wrote the mythui settings patches in #10092 |
| [13:29:57] | ** MythLogBot http://code.mythtv.org/trac/ticket/10092 ** | |
| [13:30:19] | stuartm: | knightr, kenni: ? |
| [13:31:47] | stuarta: | stuartm: you need to look at ./mythtv/configure.ps1 for the msvc builder |
| [13:31:50] | jya_: | stichnot: the whole InitByteContext, where we call avio_alloc_context and provide read/write and seek routine |
| [13:31:57] | jya_: | none of them is official |
| [13:32:26] | stichnot: | jya_: ok, I'm not familiar with that part so I'll have a look |
| [13:33:36] | jya_: | stichnot: it's the whole ring buffer bit... and how we connect our various ring buffer to ffmpeg |
| [13:34:42] | jya_: | it broke a few times after upgrading ffmpeg, i've made it in a way that it's less likely to break in the future, but whenever I had an issue in how ffmpeg was calling our own seek/read/write, the answer was always the same: this is not official api |
| [13:35:13] | stichnot: | ok yeah, I've messed with that wrapper once before |
| [13:35:42] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [13:36:06] | stuartm: | stuarta: not seeing anything referencing the delete files in there (btw, eww) |
| [13:36:20] | stichnot: | but hopefully that's orthogonal to timecode versus file offset versus frame number seeking |
| [13:37:18] | stuarta: | stuartm: powershell :( |
| [13:37:47] | stichnot: | I think taylorr also advised me to use timecodes internally instead of frames, but I stuck with the path of least resistance :) |
| [13:37:50] | stuartm: | I still think it's not doing a distclean |
| [13:39:08] | stuarta: | stuartm: i'm fairly sure it's not. apparently builds in that environment take well over 1hr per build, no ccache or equivalent |
| [13:39:17] | stuartm: | grep'd the entire source, no mention of virtualkeyboard_qt.h any where, but that build is complaining that it cannot build it |
| [13:40:30] | stuartm: | stuarta: how does anyone develop anything on Windows without an equivalent to ccache? |
| [13:41:28] | stuartm: | ffs, make uninstall – which fails to remove old libs, still managed to delete my theme |
| [13:41:51] | stuarta: | stuartm: apparently they make heavy use of precompiled headers |
| [13:41:52] | stuartm: | it's only supposed to delete stuff it installed in the first place ... |
| [13:42:24] | stuarta: | not that it can manage that :-/ |
| [13:44:11] | stuartm: | what we need is for make uninstall to work from an install log instead |
| [13:44:19] | stichnot: | stuartm: I'm going to avoid "make uninstall" and hope the bizarre frontend problems show up when I have old versions of libs lying around |
| [13:44:42] | stuarta: | stuartm: i like my make uninstall. rm -rf /usr/local/myth-git/ |
| [13:50:30] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [13:55:23] | stuartm: | replacing the X11 calls in DisplayRes with qt is a non-starter, seems they are used for more than getting the present screen resolutions, but also which resolutions are supported for those screens/drivers when resolution switching is enabled |
| [13:57:55] | stuarta: | stuartm: is there anyway of using Qt as a starting point? ie. determine if we do have X and then go and ask it for what we need if it exists? |
| [13:59:20] | stuartm: | stuarta: oh yeah, we can do that easily enough and we already are to support OSX (strangely no evidence of windows support there) |
| [14:00:33] | stuarta: | windows is strange |
| [14:18:28] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 245 seconds) | |
| [14:19:47] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 260 seconds) | |
| [14:23:14] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [14:25:46] | jya: | stuartm: that's using the nvidia xorg extension... unfortunately, i don't know another way to check frequency rate supported, not even xrandr provide such level of details |
| [14:28:30] | danielk221 (danielk221!~danielk@exchange.wgen.net) has left #mythtv () | |
| [14:28:53] | danielk22 (danielk22!~danielk@exchange.wgen.net) has joined #mythtv | |
| [14:47:02] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 240 seconds) | |
| [14:53:19] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds) | |
| [14:54:42] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [14:59:25] | dblain: | MythBuild: force build master-win8-msvc-2010–32bit |
| [14:59:25] | MythBuild: | build forced [ETA 8m52s] |
| [14:59:25] | MythBuild: | I'll give a shout when the build finishes |
| [15:00:09] | jya: | dblain: working with plain .pro file and qmake; how do you compile following the call to qmake and the creation of the makefile ? |
| [15:01:19] | jya: | I'm trying to change how we test for features in qt (check_ecxx in mythtv/configure) which is completely wrong and ignore settings set in qmakespec.... so i'm trying to change this method so it uses qmake instead followed by make |
| [15:03:06] | dblain: | jya: on windows, if I don't worry about external dependencies, then it's as simple as: |
| [15:03:15] | dblain: | qmake, nmake |
| [15:03:48] | jya: | ok... so if I can nmake, and nmake doesn't error out, I can assume build is fine? |
| [15:04:36] | jya: | i think there's another platform to handle on bad, with make vs gmake |
| [15:05:24] | dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv | |
| [15:05:33] | jya: | wagnerrp: /\ |
| [15:07:07] | dblain: | stuarta, stuartm: powershell was my why of replacing the bash script. It verifies the environment (as configure does), but it also needs to build all the third party dependencies (including FFMpeg). It's an ugly process, but I couldn't think of a cleaner way to handle it. |
| [15:08:41] | dblain: | as for the build: I wasn't doing a distclean, but I can add it. I'm not forcing a clean build due to the time it takes. Leaving the old obj files and having msvc determine what needs to be compiled due to differences in the source is the closest thing to ccache we have. |
| [15:08:52] | jya: | dblain: for testing if there's support for webkit for example, I would create a tmp.pro with QT+= webkit SOURCE = blah.cpp ; then run qmake, then make |
| [15:09:45] | jya: | on the rpi, the qmakespecs provides extra libraries and headers in a different location (/opt/vc) I can't read that information simply looking at qmake output |
| [15:09:56] | dblain: | jya: why the tmp.pro file? It should be able to be added as a condition in the normal .pro file |
| [15:10:27] | jya: | oh this is just part of the configure script, to determine what is and what isn't supported |
| [15:10:50] | jya: | so you can do things like "error Qt WebKit not supported" |
| [15:11:14] | dblain: | One thing I learned with mythtv's configure script... it's basically the FFMpeg configure with some Mythtv specifics sprinkled in. |
| [15:11:20] | jya: | currently, it only attempts to build a dummy cpp file with #include <QtWebKit/QtWebKit> and see if it fails |
| [15:11:38] | dblain: | We could do almost everything with just a pro file! |
| [15:11:42] | jya: | i'm (unfortunately) aware of this |
| [15:15:24] | jya: | doubt providing the same functionality as configure with a qmakefile would be trivial though |
| [15:16:22] | papertigers_ (papertigers_!~papertige@pool-96-243-22-90.bflony.fios.verizon.net) has joined #mythtv | |
| [15:16:36] | shodan45 (shodan45!~chris@71-15-44-176.dhcp.thbd.la.charter.com) has quit (Quit: Konversation terminated!) | |
| [15:16:37] | dblain: | I guess that is one area where Windows makes it easier (not as many variations to the environment) |
| [15:17:49] | dblain: | Are you testing for webkit support to just avoid doing a partial compile before it fails? |
| [15:21:05] | jya: | dblain: i'm doing webkit support, because it's already there in the configure |
| [15:21:31] | MythBuild: | build #73 of master-win8-msvc-2010–32bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . it/builds/73 |
| [15:22:11] | jya: | there are a few qt tests that are made where configure will exit early with an error if they do not exist: OpenGL, webkit, qtscript |
| [15:22:12] | dblain: | oh, didn't realize it. I know it disables webkit for Qt 5 in the pro files. (guess I have tunnel vision)... sorry to waste your time! |
| [15:23:10] | jya: | currently, those test fails due to OpenGL libs not being found in the usual location. the qmakespec properly set the cflags, cppflags and ldflags so compilation will work |
| [15:23:26] | jya: | but due to the way we test, it's not aware of it... so build fail |
| [15:24:02] | jya: | so i have to manually provide a --extra-cflag --extra-cppflag etc... which is a pain |
| [15:24:12] | jya: | i'd like to automate all of this |
| [15:24:28] | stuarta: | i like your plan |
| [15:25:59] | jya: | could also use pkg-config, but if you've manually configured and build qt5 like I did, there's no pkg-config set for a particular package |
| [15:26:55] | jya: | oh well,,, had a power outage 40 minutes ago here.. i'm still in the dark, can't really work as my file server is down... so off to bed. |
| [15:28:33] | danielk22: | FYI Disabling webkit with Qt5 is probably not necessary anymore. It was a workaround when we first started porting to Qt5 and webkit for Qt5 didn't compile yet. |
| [15:34:56] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [15:53:47] | stichnot (stichnot!~stichnot@207.198.105.23) has joined #mythtv | |
| [15:53:48] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [15:53:48] | stichnot (stichnot!~stichnot@207.198.105.23) has quit (Changing host) | |
| [16:02:57] | tonsofpcs: | Pi is $35ish |
| [16:03:03] | tonsofpcs: | bah, stuck in scrollback again |
| [16:04:06] | stuarta: | haha |
| [16:04:44] | dblain: | Anyone know how to use the buildbot goStepIf parameter to test if a file exists on a slave? ( I only want to call "nmake distclean" if the makefile exists) |
| [16:05:04] | dblain: | s/goStepIf/doStepIf |
| [16:06:00] | stuarta: | should be in the buildbot manual |
| [16:06:44] | dblain: | been reading it. There is a FileExists command, but when I try to use it as part of the doStepIf, it throws an exception. |
| [16:08:30] | knightr: | stuartm, just saw your ping but I haven't yet seen what it was related to... |
| [16:08:34] | stuarta: | what's the exception |
| [16:09:42] | dblain: | stuarta: Failure: twisted.internet.defer.FirstError: FirstError[#0, [Failure instance: Traceback: <type 'exceptions.TypeError'>: 'FileExists' object is not callable |
| [16:09:42] | ** MythLogBot http://code.mythtv.org/trac/ticket/0 ** | |
| [16:09:58] | stuartm: | knightr: I know someone here knew Xavier Hervy from elsewhere, and I was wondering if that was either you or Kenni? |
| [16:11:37] | knightr: | nah, I thought you did... :-) |
| [16:13:04] | dblain: | stuarta: I'd even be happy with executing the "nmake distclean" and ignoring any error, but I don't see that option either. |
| [16:13:04] | stuarta: | dblain: there might be an alternative native python call that would do the trick |
| [16:13:47] | dblain: | Do you think that parameter runs on the slave? |
| [16:14:12] | ** dblain starts reading up on python to test it. ** | |
| [16:14:18] | stuartm: | knightr: OK, thanks |
| [16:20:24] | gigem: | stuartm: Could it have been iamlindoro or markk? Trying to resurrect Xavier's patch was on my TODO list for 0.28, but it's been pushed down by something else I'm contemplating. |
| [16:20:48] | knightr: | stuartm, extremely minor nitpicking but I thought images/pictures were not necessarily photographs... |
| [16:20:53] | stuarta: | dblain: yeah, the steps run on the slave |
| [16:21:03] | knightr: | np... btw... |
| [16:21:49] | stuartm: | knightr: I know, but I deliberately chose photographs to disambiguate from stuff like Fanart/Coverart |
| [16:22:03] | knightr: | ah, good point... |
| [16:22:09] | dblain: | stuarta: I knew the steps ran on the slave, just wasn't sure if the condition was used to build list of steps to send to slave |
| [16:22:49] | stuarta: | i would expect the steps to be sent regardless, since they need evaluating on the slave |
| [16:23:11] | stuarta: | unless of course you have to use an earlier step to set a boolean and proceed that way |
| [16:23:18] | dblain: | would make sense |
| [16:23:31] | knightr: | Anyway we can translate it now so we could show something which would disambiguate it further in the translation while still keeping Photographs as the storage group name... |
| [16:23:51] | knightr: | thank you for looking into it btw...! |
| [16:23:58] | stuartm: | besides which, I can't imagine many people would want to use an image gallery for viewing anything other than photographs, you're not likely to point it at a directory containing the system wallpapers |
| [16:24:56] | stuartm: | knightr: I've other fixes I'm working on for the gallery, should be able to push them tonight |
| [16:25:09] | knightr: | maybe (art) drawings or computer generate stuff like fractals... |
| [16:25:16] | tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has quit (Ping timeout: 260 seconds) | |
| [16:26:07] | knightr: | stuartm, if you can avoid touching the translation stuff it would be appreciated, I have something I haven't committed yet (and will only be able to commmit it in 7 hours at least...) |
| [16:26:18] | stuartm: | maybe, but it's unlikely to be the majority use case |
| [16:26:41] | stuartm: | knightr: it's currently all in the scanning/utility (i.e. backend) side of things |
| [16:26:58] | knightr: | s/generate/generated |
| [16:28:08] | knightr: | thank you! I guess you'll fix the path issues at the same time... |
| [16:28:27] | stuartm: | that's what I'm attempting to achieve :) |
| [16:28:57] | knightr: | LOL... Thank you! |
| [16:29:57] | tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has joined #mythtv | |
| [16:30:15] | knightr: | BTW, what I saw in the logs, is it really a bug with the storage group code as I thought? (caused by the weird parameters passed but a bug nonetheless) |
| [16:30:43] | stuartm: | attempting to have it mirror mythmusic's logic, storing only filenames or relative paths instead of storing the absolute url for each file/directory |
| [16:31:11] | stuartm: | knightr: can't remember what you were seeing (exactly)? |
| [16:31:28] | knightr: | yep, that makes sense (and was what I was expecting to see, obviously not what was passed) |
| [16:31:55] | knightr: | http://pastebin.com/jeisCDYW |
| [16:32:30] | knightr: | look at the path it uses at the end... :) |
| [16:33:55] | stuartm: | that final bit looks like a bug, but it's probably only in the way the error message has been constructed |
| [16:35:08] | knightr: | not sure, there is code to contatenate a path to the filename which could do that before the error message is constructed... |
| [16:35:29] | knightr: | I would have to add more logging to know what was in those variables to be sure... |
| [16:35:33] | stuartm: | tbh, the service api calls need re-writing, as I think Paul commented it should be sending three args – relative path, storage group name and host |
| [16:35:47] | ** dblain idea won't work because the makefile is in git! (qmake re-generates it for windows, overwriting what from git)... oh well. ** | |
| [16:36:16] | stuartm: | defeats one of the aims of storage groups to be using absolute paths |
| [16:37:00] | knightr: | the DeleteFile service already allows (but doesn't force) passing the first two but not the host IIRC... |
| [16:37:31] | dblain: | stuartm: I just saw the logs from knightr and would need to verify with the code, but could it be that the path is just used to pass storage group> |
| [16:37:43] | knightr: | yep, he was only using the storage group to get the path I guess.... |
| [16:39:15] | knightr: | (that was in reply to stuartm, dblain I think he passed it in the filename but doesn't provide a storage group and this apparently causes a scan in all the (special?) storage groups... |
| [16:39:31] | stuartm: | well host may be largely theoretical at this point, ideally the master should be able to determine that for itself |
| [16:39:36] | knightr: | it doesn't find anything in those and builds that last weird path... |
| [16:40:13] | dblain: | just looked at the code... either way, it's inconsistent with the other methods so it should be changed. |
| [16:40:40] | knightr: | are storage groups unique to a setup (I guess so) so your are right... |
| [16:40:54] | stuartm: | searching across all storage groups, especially for file deletion is just dangerous – could easily match the wrong file entirely |
| [16:41:01] | knightr: | s/your/you |
| [16:41:10] | knightr: | LOL, extremely good point... |
| [16:42:03] | knightr: | I didn't understand why it scanned all those storage groups but I guess there must be a reason but you are absolutely right that for deleting this is dangerous... |
| [16:43:44] | stuartm: | it's built-in storage group behaviour to search all storage groups when trying to find a file, but the logic behind it is weak |
| [16:45:04] | stuartm: | searching all directories in a storage group, yes that's great, but searching all storage groups means spinning up drives unnecessarily, causes a failing search to take longer and can potentially return the wrong file |
| [16:54:50] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:c85a:e665:99e3:7e42) has quit (Quit: Leaving) | |
| [16:55:39] | knightr: | if nothing depends on that behavior it might be a good candidate for your fire sale... :) |
| [16:57:08] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [17:02:48] | Chutt_ is now known as Chutt | |
| [17:10:45] | sphery: | searching all storage groups has nothing to do with whether or not all hard drives are spun up, as usually--at minimum--the Default storage group (which is where the majority of recordings exist) is a list of directories that are spread across all disks |
| [17:10:55] | sphery: | so searching even just the Default SG means you spin up all disks |
| [17:11:12] | sphery: | and, yes, we /should/ be searching all SGs if the recording/video isn't found in the one we expect |
| [17:11:48] | sphery: | but storing the actual "last-known" location so that we only ever search as a last resort makes sense |
| [17:15:56] | sphery: | (in other words, we should do the right thing, assuming data is correct, but then try to fix the problem if the video isn't where we expect before we alert (and inconvenience) the user with an error message) |
| [17:21:09] | stuartm: | sphery: you're assuming that everyone has configured their storage as you have |
| [17:21:52] | sphery: | no, I'm just saying that SG means a list of directories, so we can't assume that each SG means a single disk and/or file system |
| [17:22:29] | sphery: | and the problem isn't that it's smart enough to search all possible locations where the video exists before giving an error |
| [17:22:33] | stuartm: | sphery: searching for a video in the music storage group is both pointless and actually pretty inefficient, instead of users realising that they have either mis-configured or put the file in the wrong place we're quietly ignoring the mistake |
| [17:22:44] | sphery: | the actual problem is that we don't store the actual physical location where it should be and search it first |
| [17:23:46] | sphery: | and same should apply for music or gallery images or whatever... store where it should be and if it's not there, search all other possibilities (and update the "where it should be") before we fail |
| [17:24:00] | stuartm: | sphery: right and searching all _directories_ in a storage group is perfectly reasonable, but someone who has put their videos on an entirely separate disk doesn't want that disk spun up when looking for a recording |
| [17:24:29] | stuartm: | I think you're confusing groups with directories |
| [17:24:41] | sphery: | No, I'm the least likely person to do that |
| [17:25:03] | stuartm: | well that's the only scenario where what you're saying makes sense |
| [17:25:10] | sphery: | I'm saying we should make it so that we don't have to do /any/ searching for videos except in extraordinary circumstances |
| [17:25:22] | sphery: | i.e. store the actual location and problem solved |
| [17:25:34] | sphery: | we don't spin up anything except the disk where the content exists |
| [17:25:36] | stuartm: | sphery: I agree with that, but I also believe that it should NOT search unrelated storage groups |
| [17:25:58] | sphery: | well, if you add in support for defining what's related and what's not, that's fine |
| [17:26:14] | sphery: | or, for a poor man's hack, you can just make the tv search exclude any built-in SGs |
| [17:26:32] | sphery: | but users should be able to move recordings from a directory in one SG to a directory in another |
| [17:26:56] | sphery: | and since we have no UI for doing that (such that it updates the SG), we should at least search all TV SGs for TV content |
| [17:27:26] | stuartm: | sphery: why? That's the bit that doesn't make sense to me – a recording storage group should contain only recordings, ditto for videos, music, photos and fanart |
| [17:27:40] | sphery: | but we have no way of specifying what's a recording sg |
| [17:27:58] | sphery: | we have default, users can define any number of SGs (which are, presumably, recording ones) |
| [17:28:18] | sphery: | and the only things that aren't--at this point, but that could change with some improvements to the UI--are built-in SGs for Videos and DB Backups and such |
| [17:28:32] | stuartm: | well not for user-defined storage groups, that I'll concede, but if that's the sticking point then that's what we should fix – ask the user to select from a list what type of media the storage group contains |
| [17:28:39] | sphery: | so we have to search every SG except built in for TV |
| [17:29:01] | stuartm: | but it's only recordings anyway where we allow users to define alternate storage groups, everything else assumes the built-in group |
| [17:29:05] | sphery: | and yeah, that would be fine--if you extend SGs to allow specifying a media type(s) |
| [17:29:34] | stichnot: | stuartm: I like to dump my camera contents into a single "backup" directory, and use that as one of the image gallery SG dirs. The camera contains photos and videos, so it's great if I can also play a video out of the photos SG. |
| [17:29:42] | sphery: | and if you do that, add support for other properties, too, that could be used for other things (such as breaking up Videos SGs or directories to specify TV content vs movies vs ...) |
| [17:30:26] | stuartm: | stichnot: to allow mythvideo say to play videos out of that directory you can just add that directory to the video storage group |
| [17:30:35] | sphery: | but right now, all we have are TV = everything except built-in SGs and Videos = only Video Library Videos and Music = only MythMusic music |
| [17:32:33] | stuartm: | sphery: I'm not really sure it's necessary to have more than one storage group per type of media, recordings it makes a _little_ sense since we're actually writing the files and users may want to keep their childrens recordings physically seperated (easier archiving/backup?) |
| [17:33:10] | stuartm: | but for every other type of media we're just read-only |
| [17:34:16] | sphery: | right, which is why we could just exclude built-in SGs from the TV search and, if searching a built-in SG, have it search only that SG |
| [17:34:43] | stuartm: | that's all I was proposing from the beginning :) |
| [17:35:03] | sphery: | OK, I didn't read enough scrollback, so I missed some of the details |
| [17:35:40] | sphery: | but that works for me--as long as we don't just say, "Well, I didn't find the TV in any Default SG directory, so I'm giving up." |
| [17:37:24] | SteveGoodey (SteveGoodey!~steve@host86-132-98-69.range86-132.btcentralplus.com) has joined #mythtv | |
| [17:37:41] | stuartm: | e.g. I have my videos on a NAS which spends most of it's time in standby, waking that up to try and find a missing recording/music track or bit of fanart is annoying – for a start it takes a few seconds to wake up, which causes the frontend in turn to block while it waits |
| [17:39:15] | stuartm: | it also adds to the wakeup count on my WD Green EARS which is already 3x over the wakeup fail point thanks to some sumpremely stupid firmware which was apparently not tested on linux |
| [17:39:15] | sphery: | Yeah, that would be fine--though ideally, that wouldn't happen often at all (recordings, etc., shouldn't go missing or we have bigger problems--though I'll concede it may happen often enough on a development system to be annoying) |
| [17:39:30] | stuartm: | supremely |
| [17:39:44] | stichnot: | stuartm: sure, but if my family is browsing camera photos on the big screen, no one wants to switch into Video Gallery to play a video in the middle of the photo sequence |
| [17:40:13] | sphery: | FWIW, WD has said that the SMART tools are pulling the wrong number/the firmware doesn't report the right number (though I've used wdidle3 to set mine to a 5min sleep time) |
| [17:40:42] | sphery: | (the fail point number is wrong on those disks, according to WD--not the number of wakeups) |
| [17:40:43] | stuartm: | stichnot: then you're fine, no-one is suggesting that the Photos storage group only contain images – we're just saying that mythvideo shouldn't be looking for videos there unless explicitly asked to |
| [17:41:32] | stuartm: | we've always supported playback of video from mythgallery and that's not about to change (I too have a lot of video from my camera) |
| [17:41:46] | stichnot: | stuartm: sorry, I was actually only responding to your comment "besides which, I can't imagine many people would want to use an image gallery for viewing anything other than photographs, you're not likely to point it at a directory containing the system wallpapers" |
| [17:42:19] | stichnot: | wasn't weighing in on the current discussion... :) |
| [17:42:42] | stuartm: | stichnot: oh right, well I was naturally including videos from the camera in that |
| [17:43:36] | ** stuartm is saving up to get a GX7 :) ** | |
| [17:45:19] | stuartm: | sphery: sadly wdidle just fails on my machine, think it's something to do with a hardware/bios incompatibility, I ended up moving that drive out of the rotation and using it for videos which I can easily re-rip should it fail |
| [17:45:33] | stuartm: | it hasn't yet, fortunately |
| [17:50:07] | drrngrvy (drrngrvy!~darren.ga@31.221.37.8) has quit (Quit: Leaving) | |
| [17:50:29] | Captain_Murdoch: | stuartm, I don't think it was mentioned, but perhaps 'Gallery' instead of Photographs, since like you (IIRC), I've started just copying my camera's memory card into the gallery directories so they're sometimes mixed images and videos. possibly best to tie the name to what the code/menu calls it to help users relate the two. |
| [17:50:49] | drrngrvy (drrngrvy!~darren.ga@31.221.37.8) has joined #mythtv | |
| [17:53:28] | stuartm: | works for me, I was thinking in terms of the current storage groups describing what they contain rather than the component they belong to |
| [17:54:08] | stuartm: | we could/should add some help text for each group to help users |
| [17:55:12] | stuartm: | just realised, belatedly that the biggest missing feature from this new code is RAW support |
| [18:01:18] | stuartm: | still, that's one reason I kept the old plugin around, so I could dismantle it for parts to use in the new one |
| [18:05:10] | jwhite_ is now known as jwhite | |
| [18:05:16] | sphery: | stuartm: the dcraw support (runs dcraw as an external program to convert to a format we understand) added by #7745 is a bit of a hack (but adds support for raw image format if you have dcraw installed when you configure), but ideally would be replaced with code that uses libraw ( http://www.libraw.org/ ) |
| [18:05:16] | ** MythLogBot http://code.mythtv.org/trac/ticket/7745 ** | |
| [18:06:54] | stuartm: | sphery: yeah, I was just googling to see what the options were, I didn't really intend re-using the dcraw stuff, it was a terrible hack |
| [18:08:18] | stuartm: | trying to find a list of supported cameras on the libraw site |
| [18:09:12] | sphery: | yeah, seems libraw is the best option (based on the searching I did a while back). It even lists why it's better (including planned improvements) over dcraw: http://www.libraw.org/about#better |
| [18:09:14] | stuartm: | I'm guessing it's the same as DarkTable which should be good ... |
| [18:12:56] | stuartm: | ok, from the changelog it supports my current camera, and the alpha adds support for my next camera :) So looks like a good option |
| [18:13:01] | sphery: | yeah, I don't see any nice list of supported cameras (only mentions of "added support for" in changelog) |
| [18:13:41] | stuartm: | heh, even supports the Blackmagic Cinema |
| [18:14:20] | sphery: | hehe, that sounds good enough for me (supports the cameras of the person thinking of adding support :)... though it does seem that it supports those that dcraw does and quickly adds support for at least new ones dcraw adds |
| [18:15:56] | stuartm: | at a minimum it would need to support my camera otherwise testing it properly would be that much harder |
| [18:16:05] | sphery: | true |
| [18:18:50] | sphery: | was looking at compatibility charts for libraw at http://upstream-tracker.org/versions/libraw.html and it seems they do pretty well at keeping compatibility at the minor version level with not-too-frequent minor-version changes, so may be able to use the system-installed version without too much extra support work, but I'll definitely leave that up to the one who does the work |
| [18:18:53] | stuartm: | will have to add smarts to the scanner so that it ignores the jpeg version if there is a raw available, or vice-versa (probably configurable – jpeg should be faster, but for some will still want the raw) |
| [18:19:45] | stuartm: | sphery: given the frequency at which new cameras are released, I wouldn't want to import that lib and have to keep it synced |
| [18:20:13] | dblain: | stuartm: Not sure how you were planning on implementing the libraw support... but may I suggest you only compile the dependent code if the library is present? (that way it won't immediately break the windows build) |
| [18:20:59] | stuartm: | dblain: won't happen immediately, but I'll aim to keep it an optional dependency |
| [18:21:25] | dblain: | thanks. |
| [18:23:26] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Ping timeout: 240 seconds) | |
| [18:23:47] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds) | |
| [18:24:28] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [18:24:44] | jpabq (jpabq!~quassel@174-28-147-195.albq.qwest.net) has joined #mythtv | |
| [18:24:45] | jpabq (jpabq!~quassel@174-28-147-195.albq.qwest.net) has quit (Changing host) | |
| [18:24:45] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv | |
| [18:40:59] | drrngrvy (drrngrvy!~darren.ga@31.221.37.8) has quit (Ping timeout: 248 seconds) | |
| [19:04:16] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [19:23:11] | stuartm: | danielk22: on backend startup it appears we open each card, attempt intial tuning etc, I assume there is a good reason for that, but what there doesn't seem to be explainable is why we do it for each virtual tuner instead of once per card? It added 20+ seconds to the startup of the backend for me which is significant if you're recovering from a restart/crash and want it to resume recording as quickly as possible |
| [19:23:16] | drewvs (drewvs!~drew@bastion.milestonesystems.com) has joined #mythtv | |
| [19:23:47] | drewvs is now known as tesla_dv | |
| [19:25:46] | stuartm: | this even happens before the backend starts listening on for connections so it's unreachable during that period |
| [19:26:41] | dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Quit: Ex-Chat) | |
| [19:29:32] | peper03: | stuartm: I tried to look into that a while back. I run a combined FE/BE that doesn't run 24/7 so I get that delay every time anyone wants to watch something. I think I found an intentional delay of about 1 second per tuner, but as you say, that's also applied to virtual tuners. |
| [19:32:13] | peper03: | Just have to rack my brains to remember what I found (certainly no immediately obvious one-liner fix)... |
| [19:46:14] | xris: | grumble/wtf: http://www.complaintsboard.com/complaints/myt . . . c684070.html |
| [19:48:50] | sphery: | hehe, seems someone doesn't realize that spammers don't use their real domain names when they make up e-mail addresses |
| [19:49:37] | xris: | yeah |
| [19:49:48] | xris: | and then someone from improveyourimage.org submitted to our feedback form about it. |
| [19:49:56] | xris: | wtf I have to create an account to reply to the complaint. that's lame. |
| [19:50:26] | xris: | I wonder if it's the same person. heh |
| [19:54:33] | dekarl: | stuartm, what is the use case for "raw preferred to jpeg"? Imho it makes sense if we do tone mapping in a shader or similar. But then we might as well support the users in converting the .raw to .exr :) |
| [19:55:11] | dekarl: | xris, what is that site? Don't they moderate new users first posts? |
| [19:55:38] | xris: | beats me |
| [19:55:48] | xris: | looks like a site of complaints about crappy scammy websites |
| [19:56:05] | ** Captain_Murdoch wonders if that's a way for them to get your info. :) ** | |
| [19:56:09] | xris: | yeah |
| [19:56:20] | dekarl: | could do with some text like "if you got spam its likely that the domain is unrelated"... |
| [19:56:48] | xris: | looks like the account was created 2 days before the improveyourimage ping |
| [19:57:25] | xris: | nah, I really suspect that it's this other place just trying to scare small businesses into paying for image monitoring services |
| [19:57:53] | stuartm: | dekarl: generally cameras perform some degree of processing to jpeg, dedicated photographers may prefer to see the unvarnished version especially if they are (for some inexplicable reason) using the gallery as a way of reviewing a days work on a TV (instead of a much higher res desktop screen ...) |
| [19:58:12] | xris: | stuartm: no pro photographer is going to review RAW files in a tv |
| [19:58:32] | stuarta: | so that use case can be scratched from the list |
| [19:58:34] | stuartm: | xris: you'll note that I carefully avoided using the term 'pro' |
| [19:58:37] | xris: | heh |
| [19:58:52] | xris: | still nice to have support for RAW (in all of its variations) |
| [19:59:58] | stuartm: | I agree it's not a great use case, but if we have raw support, and if as I propose we only show one file where the user has shot jpeg+raw, then there are going to be those who want to see the raw version instead of the in-camera processed jpeg |
| [20:00:18] | xris: | but yeah, cameras do an amazing amount of processing to create jpg files. jpg files from my new 70d look WAY better than the RAW files. have to do a lot of manual processing (sharpening, etc) before they even look remotely decent |
| [20:00:29] | xris: | stuartm: yeah that's definitely a good use case. |
| [20:00:49] | doev (doev!~doev@p4FD415E3.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds) | |
| [20:01:23] | skd5aner (skd5aner!~skd5aner@50-90-5-146.res.bhn.net) has quit (Read error: Connection reset by peer) | |
| [20:01:46] | skd5aner (skd5aner!~skd5aner@50-90-5-146.res.bhn.net) has joined #mythtv | |
| [20:05:24] | dekarl: | stuartm I was just wondering if its worth to add yet another option for users to mess with (the prefer raw or jpeg option) |
| [20:09:05] | danielk22: | stuartm: The checking each tuner code is over a decade old. When it was first added this took a few milliseconds per tuner and there were no virtual tuners. It still exists because it hasn't been painful enough for anyone to refactor it. |
| [20:09:28] | ** stuarta hands stuartm some napalm ** | |
| [20:13:46] | Guest59384 (Guest59384!~neon@bzq-79-176-185-144.red.bezeqint.net) has quit (Ping timeout: 246 seconds) | |
| [20:16:57] | stuartm: | danielk22: ok, in that case I wonder whether it still serves any purpose for DVB? Or any other card type? |
| [20:17:20] | stuartm: | if the whole thing was just removed, what would be the fallout, if any? |
| [20:18:19] | danielk22: | stuartm: It serves the purpose of telling you about some missconfigurations at startup rather than at the first attempt to use the recorder. |
| [20:19:05] | stuarta: | so we should move it to the setup step |
| [20:19:06] | stuartm: | danielk22: that's what I thought you were going to say, but it's only going to do that if you are monitoring the logs on startup or |
| [20:19:20] | danielk22: | stuartm: It requires refactoring in tv_rec.cpp which is big and scary. |
| [20:19:22] | stuartm: | right, if it's done anywhere, it should be in mythtv-setup |
| [20:20:07] | danielk22: | yeah, it would be nice to inform outside of logs of a broken config :) |
| [20:20:09] | stuarta: | stuartm: keep in mind that we want to be able to configure the whole thing with the backend online, so we should be able to "trigger" the check from mythtv-setup |
| [20:21:17] | dblain: | It would also be nice to be able to start-up a recorderless backend (which that code stops us from doing) |
| [20:22:55] | stuarta: | oh i have plans for the backend |
| [20:23:01] | danielk22: | dblain: That shouldn't be preventing a recorderless backend. |
| [20:23:15] | stuarta: | i want it to startup, and run, without even being able to connect to a database |
| [20:23:27] | stuarta: | so that then you can configure all that stuff |
| [20:23:37] | danielk22: | dblain: AFAIK The only thing preventing it at this time is a recorder count != 0 check and our willingness to support that config. |
| [20:25:24] | dblain: | danielk22: true, the count != 0 caused me to configure a recorder which was offline and then the backend would fail to start since it couldn't tune to it's initial channel. |
| [20:25:57] | danielk22: | dblain: right, so we can just get rid of the count != 0 check |
| [20:26:06] | dblain: | agreed. |
| [20:31:28] | dblain: | stuarta: I'd like that as well. I worked on getting the code to compile in msvc so I could work on the services and setup, but the windows build is taking all my time to get right :( |
| [20:33:10] | gary_buhrmaster: | stuartm, danielk22: (while testing each virtual tuner makes no sense), testing for the running of a real tuner at startup had (to me) the advantage that if a device is not available at startup (I used to have some USB tuners that randomly hung at boot time), the scheduler would choose other tuners to use. |
| [20:35:50] | stuarta: | gary_buhrmaster: yes that's true, i've a usb tuner which sometimes goes out to lunch |
| [20:37:00] | stuarta: | in which case the check actually should be more often, because it would fail recordings constantly |
| [20:37:53] | stuarta: | thats something to add to the list of things to check. i did have 1) channel lineup changes 2) eit data. now we have 3) check tuners still work |
| [20:41:28] | stuartm: | on a related note, my DVB-T tuner keeps requiring the driver be unloaded/reloaded, I thought it was a random occurance but I think I'm starting to notice a pattern and that it's related to my interrupting the backend – suspect we're not closing it down properly |
| [20:42:03] | stuarta: | hmmm, wonder if that's why my usb stick goes out to lunch |
| [20:44:12] | stuartm: | heh, with a recording made tonight I've got in-sync audio with the right channel and completely out of sync audio from the left channel (15–20s) |
| [20:45:02] | stuarta: | don't watch that after a few beers... |
| [20:45:31] | stuartm: | I thought I remembered an option to independently mute the left/right channel which would make this watchable, but I can't seem to find it |
| [20:46:12] | ** stuartm sticks a cushion in front of the left speaker ** | |
| [20:47:07] | stuartm: | hmm, better yet, I can adjust the balance in alsamixer :) |
| [20:47:30] | stuarta: | i'll remind you tomorrow to fix the balance |
| [20:47:59] | stuartm: | thanks ;) |
| [20:48:57] | tesla_dv (tesla_dv!~drew@bastion.milestonesystems.com) has quit (Quit: Ex-Chat) | |
| [20:50:42] | gary_buhrmaster: | stuarta: Yes, I often wished that the (pre start) scheduler run would also check for tuner availability first to adjust as needed. Of course people with a "minimal" tuner number would occasionally get really strange results as tuners go and come. |
| [20:52:31] | gary_buhrmaster: | stuarta: My (personal) solution was to eliminate the USB tuner (actually, my first solution was to replace the POS power supply that was glitching to cause the tuner to hang, but eventually I just retired the USB tuner itself; it has moved on to someone who suggested they might look into the livetv issue :-) |
| [21:02:31] | stichnot: | yep, I should have gotten to that before the Fall season started :) |
| [21:04:51] | allesmueller_ (allesmueller_!~N@188-23-60-190.adsl.highway.telekom.at) has joined #mythtv | |
| [21:05:20] | stuartm: | gary_buhrmaster: I actually wish it worked that way, the backend isn't detecting that the card is offline/broken here, instead it tries to record, produces no file but thinks that the recording is OK |
| [21:07:25] | stuarta: | :( |
| [21:08:43] | allesmueller__ (allesmueller__!~N@91-115-42-224.adsl.highway.telekom.at) has quit (Ping timeout: 248 seconds) | |
| [21:10:10] | SteveGoodey (SteveGoodey!~steve@host86-132-98-69.range86-132.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:14:35] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [21:17:30] | CeilingKitten (CeilingKitten!~CeilingKi@69-165-133-223.dsl.teksavvy.com) has quit (Read error: Connection reset by peer) | |
| [21:17:46] | CeilingKitten (CeilingKitten!~CeilingKi@69-165-133-223.dsl.teksavvy.com) has joined #mythtv | |
| [21:21:45] | gary_buhrmaster: | stichnot: NP as far as I am concerned. As I said, I have never used (or at least can not remember when I did use) LiveTV. I have no interest or standing to see it fixed. But I am happy to make old hardware relocate to others when it might enable others to fix it. And it keeps electronic waste out of the landfill. |
| [21:30:46] | jpabq: | stichnot: I have been tinkering with HLS. One of jya's complaints was how long LiveTV takes to start with it. I bet USB tuners have similar issues. Right now, after the SignalMonitor is done parsing/validating all of the 'tables', all of that data read is pretty much thrown away, and the recorder then has to start reading until it hits a keyframe. |
| [21:32:19] | jpabq: | Because the recorder is unable to take advantage of the data read by the SignalMonitor, it can almost double how long it takes to start up a recording or LiveTV. If there was an easy way to have the recorder start listening to the data at the same time the SignalMonitor does, it would make the process much faster. |
| [21:33:29] | jpabq: | I have been looking that over, and tried a few things, but am not happy with it. I have a new idea, but have not had time to give a try yet. |
| [21:35:32] | jpabq: | At least for HLS, one thing I tried that made a big difference for LiveTV, was turning OFF the wait_for_keyframe option. Yes, the user ends up seeing a couple of seconds of pixelation, but it works better because mythfrontend does not feel starved for data. |
| [21:40:28] | papertigers_ (papertigers_!~papertige@pool-96-243-22-90.bflony.fios.verizon.net) has quit (Quit: papertigers_) | |
| [21:46:20] | stuartm: | when I have tried LiveTV, it almost always struggles with HD channels, seemingly because it's not buffering enough before attempting playback |
| [21:49:27] | stichnot: | jpabq: that sounds like an issue that depends on the input source (e.g. mpeg2 with keyframe distance 15 versus hdpvr with keyframe distance 128), rather than USB related, no? |
| [21:50:43] | jpabq: | True |
| [21:50:44] | gary_buhrmaster: | stuartm: I hear (on the users list) that doing a "pause" <wait a second> "unpause" fixes it for some if it is a buffer starvation issue. |
| [21:51:49] | stuartm: | sometimes it does, if that doesn't work, pausing it long enough to then seek (I have my seek configured for 40 seconds) always works |
| [21:53:10] | stuartm: | the fact that seeking works while pausing doesn't is another bug entirely, seeking resets some things that aren't correcting themself in normal playback |
| [21:53:16] | stichnot: | It might be possible to create an initial cutlist for the section before the first keyframe, to mask the initial pixelation on subsequent playback, but that's probably overthinking things |
| [21:53:17] | stuartm: | themselves |
| [22:01:55] | gary_buhrmaster: | stichnot: While no pixelation might be a nice goal, I do not remember ever using a TV/STB which did not either pixelate or show a black screen (until, I presume, it saw a keyframe), when changing channels. I would just say "live with it". But note I am not known for my strong human factors concerns. |
| [22:05:10] | stichnot: | My biggest gripe is that you can't reduce the HD-PVR's excessive keyframe distance of 128 to something more reasonable and responsive. Editing a cutlist of an HD-PVR recording can be depressingly sluggish, as you can easily have more than 1 second response time between keypresses. |
| [22:06:50] | stichnot: | I would love to have a (presumably) simple transcoder that just inserts new keyframes at more reasonable intervals, but I suppose nothing is ever as easy as it seems it should be |
| [22:21:44] | Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer) | |
| [22:25:58] | gary_buhrmaster: | stichnot: I had this vague recollection that someone once thought they could adjust the IDR distance. But quick search on a leading search engine resulted only in a reference to a development tab on a windows driver (that no longer seems to exist). |
| [22:26:37] | stichnot: | #11885 looks like it might be related to an apparent copy&paste error in tv_play.cpp (too many instances of kPictureAttributeSupported_Brightness in TV::GetStatus() ). But I'm not sure how that would lead to the specific scenario described in the ticket. |
| [22:26:37] | ** MythLogBot http://code.mythtv.org/trac/ticket/11885 ** | |
| [22:28:44] | stichnot: | gary_buhrmaster: too bad :( |
| [22:35:00] | cecil_ is now known as cesman | |
| [22:35:15] | cesman (cesman!~cesman@pool-108-23-186-67.lsanca.fios.verizon.net) has quit (Changing host) | |
| [22:35:15] | cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has joined #mythtv | |
| [22:37:43] | gary_buhrmaster: | stichnot: I lied (well, not intentionally). There is some stub/commented out code in the Linux driver regarding possible keyframe settings. I presume it is commented out because it does not work. Perhaps Hauppauge decided what is best for you and disabled any adjustment there. |
| [22:40:11] | stuartm: | what are the filesizes like with a keyframe distance of 128? |
| [22:45:51] | gary_buhrmaster: | stuartm: You can adjust the target bitrate, but as I understand it (I never owned one), 2.5GB/hr at 720p is a typical number out of the HDPVR at high quality. 4–5GB/hr at 1080i. |
| [22:47:26] | stuartm: | ok, that's on a par with broadcast here |
| [22:47:54] | stuartm: | the 1080i anyway, we don't get 720p broadcast |
| [22:48:02] | stuartm: | occassionally 1080p |
| [22:54:20] | stichnot: | My 720p hdpvr recordings are 2–2.5 GB/hour. My ATSC recordings can be up to 7.5 GB/hour. |
| [22:55:15] | stichnot: | I'd be very happy with a keyframe distance of 32 at a cost of like 10% larger recordings |
| [22:55:29] | stuartm: | obviously there's some advantage to H.264 over mpeg-2 |
| [22:56:01] | stuartm: | the ATSC recordings are 1080i? |
| [22:56:03] | gary_buhrmaster: | stichnot: I presume that is US OTA ATSC, which means mpeg-2? (The ATSC standards now support MPEG4, but the FCC does not allow it OTA). |
| [22:57:52] | stuartm: | broadcast HD (H.264) used to be ~20Mbps here, until they 'improved' the encoding process and it dropped to ~10Mbps :( |
| [22:59:24] | stuartm: | to be fair, the drop in quality wasn't that noticable, but either I'm so used to HD now that I don't notice it or the quality isn't what it used to be 2–3 years ago |
| [22:59:35] | gary_buhrmaster: | stuartm: Did the "improvement" result in equal/higher quality, or just more channels to ignore? |
| [23:01:12] | gary_buhrmaster: | stichnot: I seem to recall that for OTA, there is a recommendation to send a keyframe (at a minimum?) every 2 seconds or so. I presume Hauppauge figured that since there would be no losses over the (highly reliable?) USB bus they could get away with a longer interval. |
| [23:01:24] | stichnot: | gary_buhrmaster: yes. Specifically, the 7.5GB/hour recordings come from the local CBS station which thankfully has no useless subchannels, so they use the full 19 Mb/s bandwidth. |
| [23:01:24] | stuartm: | gary_buhrmaster: immediately after the change I'd say it was roughly equal, but the stuff I'm seeing now lacks that pin-sharp clarity and I wonder if quality has suffered (or just my eyesight) |
| [23:02:26] | stichnot: | They can get away with a longer interval as long as no one cares about fast frame-accurate seeking |
| [23:02:34] | gary_buhrmaster: | stuartm: Or the memory. The memory is the third thing to go (after the knees; I really miss my knees :-) |
| [23:03:41] | xris: | my knees still work fine. memory went away in my twenties. |
| [23:03:48] | stuartm: | my knees went years ago, suffered with them since I was in my teens (sports related)! |
| [23:04:39] | xris: | see how smart I was to avoid exercice/sports when I was young? :) |
| [23:08:19] | stuartm: | heh, I was never what you'd call a sportsman, but some form of team sport was compulsory at school (in addition to the standard gym stuff and cross country) |
| [23:10:18] | gary_buhrmaster: | stichnot: Yes, KPIX is known for high quality HD. |
| [23:11:16] | stuartm: | didn't keep up any sport after leaving school, but I do hike and for a time I was into Sailing and Climbing (amateur stuff) |
| [23:13:40] | gary_buhrmaster: | stichnot: I should say, OTA. I recall hearing a few years ago that Comcast did not always maintain the quality (which, as I recall, made some people who watch sports very unhappy). Perhaps they (Comcast) are better now. |
| [23:25:24] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [23:25:26] | jya: | danielk22: I didn't see webkit being disabled in qt5.... or it's been reintroduced following the merge with dblain branch |
| [23:27:31] | skd5aner: | gigem: I'm still seeing scheduled recordings trying to steal a livetv tuner when there are plenty of other free tuners available in 0.27 |
| [23:30:25] | wagnerrp: | jya, dblain: yeah, on freebsd, i have to run 'gmake' rather than 'make' |
| [23:32:53] | rsiebert (rsiebert!~quassel@g225048004.adsl.alicedsl.de) has quit (Ping timeout: 248 seconds) | |
| [23:35:19] | jya: | wagnerrp: any magic command to know if you're on bad or not ? |
| [23:44:46] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.