| Saturday, March 5th, 2016, 01:33 UTC | ||
| [01:33:32] | SteveGoodey (SteveGoodey!~steve@host109-159-44-40.range109-159.btcentralplus.com) has joined #mythtv | |
| [02:05:26] | Chutt (Chutt!~ijr@2605:a000:1225:7e:c457:ef1d:60fd:2177) has joined #mythtv | |
| [02:05:38] | andreaz (andreaz!~andre_000@p4FC5602B.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [02:16:38] | SteveGoodey (SteveGoodey!~steve@host109-159-44-40.range109-159.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [03:36:02] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 260 seconds) | |
| [03:36:24] | peper03_ (peper03_!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [03:36:37] | peper03_ is now known as peper03 | |
| [04:11:30] | Roklobotomy (Roklobotomy!~blah@ppp118-209-169-137.lns20.mel8.internode.on.net) has quit (Quit: Leaving) | |
| [04:18:17] | Roklobotomy (Roklobotomy!~blah@ppp118-209-169-137.lns20.mel8.internode.on.net) has joined #mythtv | |
| [07:23:45] | Tobbe5178 (Tobbe5178!~asdf@h232n2-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
| [08:43:02] | amessina (amessina!~amessina@unaffiliated/amessina) has quit (Quit: Konversation terminated!) | |
| [09:02:24] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv | |
| [09:11:55] | andreaz (andreaz!~andre_000@p4FC5602B.dip0.t-ipconnect.de) has joined #mythtv | |
| [09:14:04] | joki (joki!~joki@p548618BA.dip0.t-ipconnect.de) has quit (Ping timeout: 268 seconds) | |
| [09:19:40] | joki (joki!~joki@p54861628.dip0.t-ipconnect.de) has joined #mythtv | |
| [09:24:08] | SteveGoodey (SteveGoodey!~steve@host109-159-44-40.range109-159.btcentralplus.com) has joined #mythtv | |
| [09:24:37] | dekarl1 (dekarl1!~dekarl@mythtv/developer/dekarl) has joined #mythtv | |
| [09:27:34] | dekarl (dekarl!~dekarl@mythtv/developer/dekarl) has quit (Ping timeout: 240 seconds) | |
| [09:27:45] | dekarl1 is now known as dekarl | |
| [09:52:25] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 252 seconds) | |
| [10:13:29] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv | |
| [10:22:16] | dekarl: | Roklobotomy: yes, our current HDHR recorder supports multirec by tuning to a frequency and picking the PIDs on its own. e.g. the EIT PID for active/passive EIT scan. In that regard the HDHR and the DVB recorder work basically identically. The original API also allows setting up the PID filter by picking a program_number/service_id and only getting that. |
| [10:23:02] | dekarl: | and the new http api only supports the automatic setup of the PID filter by selecting a service from the channel scan instead of a frequency |
| [10:25:04] | dekarl: | gigem, yes, that is my understanding, too. The client side (us) groups the devices by signal source. So if we know of three EU devices that can be connected to cable or antenna, then we have to know from somewhere how they are connected. Is it three different antennas? Are all connected to the same cable outlet via a splitter? And that's where our video sources come in, which basically describe the same concept. |
| [10:30:24] | dekarl: | knightr: looks like an encoding issue with "Mär" vs "M(symbol for unknown character goes here)r" on the users list |
| [11:07:57] | Roklobotomy (Roklobotomy!~blah@ppp118-209-169-137.lns20.mel8.internode.on.net) has quit (Remote host closed the connection) | |
| [11:42:10] | lautriv_ (lautriv_!~lautriv@f050085020.adsl.alicedsl.de) has joined #mythtv | |
| [11:42:10] | lautriv_ (lautriv_!~lautriv@funtoo/user/lautriv) has joined #mythtv | |
| [11:42:10] | lautriv_ (lautriv_!~lautriv@f050085020.adsl.alicedsl.de) has quit (Changing host) | |
| [11:44:57] | SteveGoodey (SteveGoodey!~steve@host109-159-44-40.range109-159.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [11:46:25] | SteveGoodey (SteveGoodey!~steve@host109-159-44-40.range109-159.btcentralplus.com) has joined #mythtv | |
| [11:49:00] | SteveGoodey (SteveGoodey!~steve@host109-159-44-40.range109-159.btcentralplus.com) has quit (Client Quit) | |
| [11:58:59] | knightr: | dekarl, yes |
| [12:00:05] | knightr: | I tried the setting the character set in Translate.php and that didn't work but either using utf8_encode() or htmlentities() as people suggest on the Internet as a fix for this works... |
| [12:00:33] | knightr: | some people are suggesting it's an issue with PHP's strftime() |
| [12:02:45] | knightr: | oops, I tried setting... |
| [12:08:17] | knightr: | it's weird that utf8_encode work because it's only supposed to convert ISO-8859–1 to UTF-8 and German needs ISO-8859–15... |
| [12:09:31] | knightr: | (maybe it fails for some characters...) |
| [12:10:43] | knightr: | I actually played quite a great deal with charactet sets in the past so I knew it was some sort of encoding issue |
| [12:11:20] | knightr: | (and I think Bjorn? even suggested it too...) |
| [12:36:54] | peper03: | jya: In the resync with ffmpeg 3.0 you added a block to 'configure' to creating a symlink 'src' under mythtv, which points back to mythtv (at least on my system). |
| [12:36:56] | peper03: | https://github.com/MythTV/mythtv/blob/master/ . . . figure#L5663 |
| [12:37:40] | peper03: | What exactly is that for? My IDE follows symlinks if I search in files, so it never ends because it's recursive. |
| [12:38:08] | peper03: | If I comment the first bit out (as though it weren't possible to create a symlink), everything still seems to build and run ok. |
| [13:02:05] | knightr (knightr!~knightr@69-165-170-178.dsl.teksavvy.com) has quit (Read error: Connection reset by peer) | |
| [13:09:07] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
| [13:23:29] | dekarl: | knightr: iso 8859–1 is fine for german, unless you need the Euro symbol which is in -15 (that's the main difference) |
| [14:37:27] | stuartm: | http://mythtv.co.uk/imagebin/MythTV%20Car/P1000012.JPG |
| [14:39:30] | stuartm: | http://mythtv.co.uk/imagebin/MythTV%20Car/P1000013.JPG |
| [14:39:36] | stuartm: | http://mythtv.co.uk/imagebin/MythTV%20Car/P1000014.JPG |
| [14:40:34] | stuartm: | of course this is all a bit of a cheat -> http://mythtv.co.uk/imagebin/MythTV%20Car/P1000007.JPG |
| [14:42:00] | stuartm: | car powered RPi 3 connected via HDMI connected via Wifi – i.e. it works only in the driveway, but that's a small hurdle |
| [14:50:27] | pvr4me (pvr4me!~craigtrel@d24-150-182-175.home.cgocable.net) has joined #mythtv | |
| [14:51:28] | stuartm: | not very original – but it's given me an idea about extending HLS streaming to mythfrontend |
| [14:57:39] | stuartm: | not for this purpose fwiw, it's still completely impractical to run a full frontend this way – easier to use the WebFrontend. (connecting up the RPi to the car was just an experiment) |
| [14:58:22] | amessina (amessina!~amessina@unaffiliated/amessina) has joined #mythtv | |
| [15:13:53] | knightr: | dekarl, not sure what went wrong the first time but it's fixed now... |
| [15:14:33] | gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has joined #mythtv | |
| [15:14:56] | knightr: | the PHP locale specified didn't have UTF-8... |
| [15:15:10] | knightr: | it's the field just after the language name in Translate.php |
| [15:16:41] | knightr: | so by default it was most likely using ISO-8859–1 which is why encoding it to UTF-8 with utf8_encode worked... |
| [15:17:45] | knightr: | all hell would have breaked loose most likely for Greek if I had used that... |
| [15:20:05] | knightr: | setting the character set is the first thing I tried though so I am not sure what went wrong when I tried it before, there must have been a typo or something... |
| [15:20:35] | knightr: | I have committed to master, can you confirm this works for you and if so I would backport to 0.27 and 0.28... |
| [15:20:38] | knightr: | ? |
| [15:20:52] | knightr: | only if you can, please... |
| [15:34:09] | knightr: | dekarl, as for the date format as German translator you make the call |
| [15:34:55] | knightr: | go with what is more natural in Germany (and/or other German speaking countries) |
| [15:36:07] | knightr: | thank you for the info about ISO-8859–15 by the way... |
| [15:37:46] | knightr: | we have a similar issue with ISO-8859–1 in French, it doesn't fully support French actually... |
| [15:41:16] | knightr: | normally (most people never do it though, we only see it in some printed material) in French the letters "o" and "e" written one after the other must be joined together like this "Å“" (it's called a ligature) and we need ISO-8859–15 if we want that "letter".... |
| [15:42:08] | knightr: | funny thing is the place I live should normally be written with it... (-; |
| [15:42:24] | knightr: | s/place I/place where I/ |
| [15:55:11] | gary_buhrmaster: | gigem: dekarl: btw, IRT the HDHR, it is possible to use EIT via the HTTP interface, but you have to tune by frequency/<raw>channel, and not virtual channel. You then get the stream without pid filtering. |
| [15:55:48] | gary_buhrmaster: | gigem: dekarl: Like a lot of the recent capabilities, the documentation is a bit, um, lacking. |
| [15:57:00] | gary_buhrmaster: | gigem: dekarl: So, you could get the "auto-magic" tuner selection and locking using the HTTP interface, and still do what want to do. |
| [15:59:43] | gary_buhrmaster: | gigem: dekarl: I (very) briefly looked at implementing the next gen http interface using the new external recorder capability, but then got otherwise occupied. |
| [16:01:33] | gary_buhrmaster: | gigem: dekarl: But thinking about it, I do not recall if one could manage EIT scanning using the external recorder (or multirec, for that matter). |
| [16:03:45] | gary_buhrmaster: | gigem: dekarl: But in the US, that is clearly not as much of an issue (CableCARD tuners do not share, and there are very few OTA channels that share(*) in ways such that you actually care about multirec). |
| [16:03:54] | SteveGoodey (SteveGoodey!~steve@host109-159-44-40.range109-159.btcentralplus.com) has joined #mythtv | |
| [16:04:30] | gary_buhrmaster: | gigem: dekarl: (*) FCC Auction 1000/1001 may change that in the future, but even if it does, it will not have any impact for many many years. |
| [16:10:27] | Hydr0p0nX: | is 0.27.6 or 0.28 current stable now ? |
| [16:13:57] | enyc: | Hydr0p0nX: certainly people installying/testing 0.28 is highly delsireable at this point |
| [16:14:16] | enyc: | Hydr0p0nX: but official side still just shows 0.27.6 |
| [16:16:56] | Hydr0p0nX: | thanks |
| [16:20:31] | pvr4me (pvr4me!~craigtrel@d24-150-182-175.home.cgocable.net) has quit (Quit: pvr4me) | |
| [17:24:57] | pvr4me (pvr4me!~craigtrel@d24-150-182-175.home.cgocable.net) has joined #mythtv | |
| [17:40:37] | dekarl: | knightr: I can test it in a few hours |
| [17:40:37] | dekarl: | stuartm: ahh nice idea for those loose MHL/HDMI connectors in the car. I wonder if the touchscreen fits with the touch support for android ;) |
| [17:40:54] | dekarl: | gary_buhrmaster: got a link to more complete information about the http api? |
| [17:41:38] | dekarl: | Hydr0p0nX: we are late in the release cycle before cutting the first 0.28 release. we call it beta ;) |
| [17:45:26] | gary_buhrmaster: | dekarl: Unfortunately, not really. It was documented on their forum as (for example) http://<ip>:5004/auto/v<n> for a virtual channel (with pid filtering), http://<ip>:5004/auto/ch<n> for a (raw) dump for a particular channel |
| [17:46:31] | gary_buhrmaster: | dekarl: and http://<ip>:5004/auto/ch<nnnnnnn> for a (raw) dump for a particular frequency (I guess they figure no channels will have 6+ digits in the parsing?) |
| [17:47:50] | gary_buhrmaster: | dekarl: the http development guide did not (I have not looked recently, maybe they updated it) mention the "raw" versions of the command. |
| [17:48:52] | dekarl: | gary_buhrmaster: is there anything that the http api gives us other then a chance of a full rewrite? I think now that we have a stable recorder and an idea how to move forward that the http api does not add anything besides the support for lock timeout behind firewalls |
| [17:49:38] | dekarl: | if the raw version has no PID filter, then an EIT scan of 4 transports will stream the full 4 transports over the network? |
| [17:50:03] | dekarl: | shuold not be an issue on a GigE network though |
| [17:50:17] | gary_buhrmaster: | dekarl: AFAIK they have also not (fully) documented the json channel display (after a scan, you can do http://<ip>/lineup.json<?tuning&show=all> to get useful channel info) |
| [17:50:50] | stuartm: | dekarl: pondering whether it's even possible to capture the touchscreen input – if it used MirrorLink then yes, but it doesn't right now. Pi 3 has bluetooth but I don't think the head unit will act as a bluetooth pointer device |
| [17:52:48] | gary_buhrmaster: | dekarl: SiliconDust has promised "better" documentation RSN (at best, I figure that will happen after they release their new software DVR solution). |
| [17:53:51] | stuartm: | a more practical reason to hook up the Pi will be for navigation (at least until someone hacks the head unit to allow new apps to be installed) and a better web browser/selection of useful applications |
| [17:54:28] | stuartm: | but since the Pi I was testing it out with had mythfrontend installed I had to try it :) |
| [17:57:24] | dekarl: | stuartm, I was lucky, the dealer installed a device that can be fed with proper openstreetmap maps. maybe something for next winter |
| [17:57:35] | gary_buhrmaster: | dekarl: I think the thing that the http API provides is proper sharing, in that a proper recorder instance with multiple physical devices with multiple tuners each can search for an available tuner. |
| [18:01:09] | dekarl: | gary_buhrmaster: oh nice, i didn't think that one hdhr would stream from another unit via any api |
| [18:02:17] | pvr4me (pvr4me!~craigtrel@d24-150-182-175.home.cgocable.net) has quit (Quit: pvr4me) | |
| [18:02:29] | gary_buhrmaster: | dekarl: Well, not exactly. If you ask for http://<ip>:5004/auto/v123 it will look for any available tuner in that device. But if you get a 503(? not sure, I presume a 5xx), you then have to go to the next physical device and try again. |
| [18:03:20] | gary_buhrmaster: | dekarl: There is no current API to search a set of tuners. However, if you get all the lineup.json responses, you can (estimate) which tuners share the same channels, and "auto-magically" configure. |
| [18:03:52] | gary_buhrmaster: | dekarl: As with anything else, some people have very complex variations so that auto-magic does not work well. |
| [18:04:10] | dekarl: | gary_buhrmaster: sounds like much work for little gain |
| [18:05:29] | dekarl: | gary_buhrmaster: now if that api gave tuner sharing between different applications, that would be fun ;) |
| [18:05:35] | gary_buhrmaster: | dekarl: Depends on whether sharing tuners is a goal for MythTV. If not, MythTV should lock all tuners at start-up, because that is how things work today. |
| [18:06:01] | dekarl: | gary_buhrmaster: doesn't work as the lock will break if we don't stream for 30 seconds |
| [18:06:26] | dekarl: | so we need a "lock keeper" that refreshes our locks every 15 seconds or so |
| [18:07:00] | gary_buhrmaster: | dekarl: Actually, as long as you issue the lock request every 10–20 seconds, you keep it. (fake) implementation: start new thread at startup that issues lock request continously in background. |
| [18:07:17] | dekarl: | but we can repurpose the "open on demand" logic for that with three states "no locking, on demand locking, protect my tuners" |
| [18:08:13] | dekarl: | have to start taking notes for a design... I think that can work out very well for most/all use cases |
| [18:08:17] | gary_buhrmaster: | dekarl: the http API does allow sharing tuners between apps on the same or different systems, as long as each use the same (type of) request. Obviously if you need 6 tuners and only have 4 someone loses, but the first 4 requestors win. |
| [18:09:29] | dekarl: | gary_buhrmaster: so there is multirec between applications? nice |
| [18:10:01] | gary_buhrmaster: | dekarl: No, I guess I was confused as to what you wanted. There is no stream sharing with the HTTP API between apps. Each gets their own TCP stream. |
| [18:10:51] | gary_buhrmaster: | dekarl: btw, another advantage of the HTTP stream is it addresses (within limits) the "lost UDP packet" issue, which happens all too often on poorly configured (i.e. consumer) home networks. |
| [18:11:13] | dekarl: | gary_buhrmaster: this use case 2 people ask for the same tv service and the third asks for a tv service on the same transport, how many tuners does the http api require? |
| [18:13:03] | gary_buhrmaster: | dekarl: 3 tuners. There is no tuner sharing between streams (afaik) between different apps. The apps themselves can share, of course (and if all use a MythTV BE, they may be able to join the live stream in progress). |
| [18:13:58] | gary_buhrmaster: | dekarl: So it is not as nice as one would like (especially) outside the US. |
| [18:14:00] | dekarl: | ok, so very little gain in using the http api over using the newer features of the original api |
| [18:14:48] | stuartm: | dekarl: nice ... I've previously used OSMAnd on my phone, but I want to take advantage of the bigger screen |
| [18:15:02] | dekarl: | ENOTIME for writing a new recorder, but it appears that a sound design is possible with minimal changes to our existing recorder |
| [18:16:31] | dekarl: | I was looking at smolt earlier and was reminded that half of our user base's tuners are running the HDHR recorder |
| [18:18:30] | stuartm: | idea of using the Pi 3 never occurred to me until earlier today, but I think it has real potential so I've already ordered a second one |
| [18:19:10] | gary_buhrmaster: | dekarl: I guess I see greater advantages, but with even less time, it really does not seem to matter right now. Add it all to the future wish list(s) that people keep around. |
| [18:19:31] | SteveGoodey (SteveGoodey!~steve@host109-159-44-40.range109-159.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [18:20:24] | jheizer (jheizer!~jheizer@c-73-51-93-177.hsd1.il.comcast.net) has quit (Ping timeout: 276 seconds) | |
| [18:40:00] | pvr4me (pvr4me!~craigtrel@d24-150-182-175.home.cgocable.net) has joined #mythtv | |
| [19:38:24] | xris (xris!~xris@mythtv/developer/xris) has quit (Ping timeout: 276 seconds) | |
| [19:41:30] | xris (xris!~xris@xris.forevermore.net) has joined #mythtv | |
| [19:41:30] | xris (xris!~xris@mythtv/developer/xris) has joined #mythtv | |
| [19:41:30] | xris (xris!~xris@xris.forevermore.net) has quit (Changing host) | |
| [19:59:00] | pvr4me (pvr4me!~craigtrel@d24-150-182-175.home.cgocable.net) has quit (Quit: pvr4me) | |
| [20:13:48] | lomion0815 (lomion0815!~markus@178-191-252-74.adsl.highway.telekom.at) has joined #mythtv | |
| [20:16:08] | lomion0815: | dekarl: We reached the 32 bit limit of the EITFixUp enum ... |
| [20:20:00] | lomion0815: | How to compile a enum with 64 bits length? |
| [20:32:10] | andreaz (andreaz!~andre_000@p4FC5602B.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [20:38:37] | dekarl: | lomion0815: i don't understand. what is the issue? |
| [20:39:19] | dekarl: | do we need a unit test to identify compilers silently truncating to 32bit? |
| [20:40:29] | dekarl: | https://github.com/MythTV/mythtv/blob/master/ . . . tfixup.h#L61 |
| [20:41:00] | dekarl: | https://github.com/MythTV/mythtv/blob/master/ . . . ups.cpp#L647 |
| [20:42:28] | dekarl: | https://github.com/MythTV/mythtv/commit/ef340 . . . 6cd7d437b484 |
| [20:43:14] | dekarl: | the third link is the important one... i thought i had the relevant bits in separate commits though |
| [20:47:03] | lomion0815: | ahhh, I missed the ll |
| [20:49:30] | dekarl: | me, too. The unit test helped |
| [20:51:48] | lomion0815: | As they did for me. |
| [20:52:13] | lomion0815: | I will provide a patch for Austrian ATV and german Disney Channel soon |
| [20:52:29] | lomion0815: | Including unit tests ;) |
| [20:53:27] | dekarl: | ATV can't use the P7S1 one? |
| [20:54:06] | dekarl: | ahh, I remembered wrong its not one of their stations |
| [20:55:42] | lomion0815: | Austrian tv channel |
| [20:56:38] | lomion0815: | Would you prefer a patch or a pull request? |
| [21:07:03] | dekarl: | if you have it on a feature branch on your fork on github already, then a pull request ;) but a set of patchfiles is just as good |
| [21:07:25] | peterbennett (peterbennett!~peter@c-75-67-202-199.hsd1.ma.comcast.net) has joined #mythtv | |
| [21:21:42] | gregbert (gregbert!ff9a0977@unaffiliated/gregbert) has quit (Ping timeout: 244 seconds) | |
| [21:28:09] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Quit: Lämnar) | |
| [21:40:00] | lomion0815: | Done #12679 |
| [21:40:00] | ** MythLogBot http://code.mythtv.org/trac/ticket/12679 ** | |
| [21:46:07] | Roklobotomy (Roklobotomy!~blah@ppp118-209-169-137.lns20.mel8.internode.on.net) has joined #mythtv | |
| [21:49:01] | gregbert (gregbert!5b9c9322@unaffiliated/gregbert) has joined #mythtv | |
| [21:50:59] | dekarl: | lomion0815: should the ATV fixup set category_type=series, too? |
| [21:51:59] | dekarl: | and what is the change in PBB doing? |
| [21:54:41] | peterbennett (peterbennett!~peter@c-75-67-202-199.hsd1.ma.comcast.net) has left #mythtv () | |
| [21:55:40] | lomion0815: | The change in PBB is to fix an issue where the recordings with episode/season info are ordered in reverse order than the ones without episode/season info |
| [21:55:41] | pvr4me (pvr4me!~craigtrel@d24-150-182-175.home.cgocable.net) has joined #mythtv | |
| [21:58:07] | lomion0815: | The category_type=series applies only to Disney |
| [22:12:22] | dekarl: | lomion0815: yes, that's what I wanted to know... removing ", Episode xxx" from the episode title appeared to be a good hint that its a series, too |
| [22:12:47] | dekarl: | but I've not seen that channels guide, so I don't know if that makes sense |
| [22:14:13] | pvr4me (pvr4me!~craigtrel@d24-150-182-175.home.cgocable.net) has quit (Quit: pvr4me) | |
| [22:14:32] | lomion0815: | Good point. I'll check that! |
| [22:15:02] | lomion0815 (lomion0815!~markus@178-191-252-74.adsl.highway.telekom.at) has left #mythtv ("QUIT :Leaving.") | |
| [23:53:31] | pvr4me (pvr4me!~craigtrel@d24-150-182-175.home.cgocable.net) has joined #mythtv | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.
