| Tuesday, September 16th, 2014, 00:01 UTC | ||
| [00:01:49] | fmcd (fmcd!~fmcd@pdpc/supporter/active/phpgus) has joined #mythtv | |
| [00:28:06] | sheedy-away is now known as sheedy | |
| [00:41:27] | sheedy is now known as sheedy-away | |
| [00:49:23] | Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has quit (Quit: ChatZilla 0.9.90.1 [Firefox 32.0.1/20140911151253]) | |
| [00:54:17] | koffel (koffel!~koffel@173-167-212-107-ip-static.hfc.comcastbusiness.net) has joined #mythtv | |
| [01:13:35] | koffel (koffel!~koffel@173-167-212-107-ip-static.hfc.comcastbusiness.net) has quit () | |
| [01:19:40] | enyc (enyc!~enyc@muddle.enyc.org.uk) has quit (Ping timeout: 260 seconds) | |
| [01:26:35] | enyc (enyc!~enyc@muddle.enyc.org.uk) has joined #mythtv | |
| [01:41:37] | fmcd (fmcd!~fmcd@pdpc/supporter/active/phpgus) has quit (Quit: Leaving) | |
| [01:46:26] | Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has joined #mythtv | |
| [02:37:30] | sheedy-away is now known as sheedy | |
| [02:41:54] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 250 seconds) | |
| [02:42:45] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [02:57:03] | sheedy is now known as sheedy-away | |
| [03:02:31] | jya (jya!~jya@CPE-120-148-100-149.bjzv2.vic.bigpond.net.au) has quit (Changing host) | |
| [03:02:31] | jya (jya!~jya@mythtv/developer/jya) has joined #mythtv | |
| [03:07:21] | arescorpio (arescorpio!~arescorpi@195-27-245-190.fibertel.com.ar) has joined #mythtv | |
| [03:19:36] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 250 seconds) | |
| [03:20:41] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:09:09] | ElmerFudd (ElmerFudd!~le@87-55-166-130-static.dk.customer.tdc.net) has quit (Ping timeout: 260 seconds) | |
| [04:11:15] | ElmerFudd (ElmerFudd!~le@87-55-166-130-static.dk.customer.tdc.net) has joined #mythtv | |
| [04:13:36] | arescorpio (arescorpio!~arescorpi@195-27-245-190.fibertel.com.ar) has quit (Excess Flood) | |
| [05:30:44] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has quit (Ping timeout: 260 seconds) | |
| [05:37:39] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has joined #mythtv | |
| [06:01:34] | SteveGoodey (SteveGoodey!~steve@host86-164-55-181.range86-164.btcentralplus.com) has joined #mythtv | |
| [06:13:32] | SteveGoodey (SteveGoodey!~steve@host86-164-55-181.range86-164.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [06:26:22] | gigem (gigem!~david@mythtv/developer/gigem) has quit (Ping timeout: 250 seconds) | |
| [06:28:07] | gigem (gigem!~david@pool-71-170-165-247.dllstx.fios.verizon.net) has joined #mythtv | |
| [06:28:07] | gigem (gigem!~david@pool-71-170-165-247.dllstx.fios.verizon.net) has quit (Changing host) | |
| [06:28:07] | gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv | |
| [06:31:24] | Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has quit (Ping timeout: 260 seconds) | |
| [06:39:08] | FabriceMG (FabriceMG!~Thunderbi@LCaen-656-01-100-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [06:46:27] | dekarl: | wagnerrp: you seem to know about exported version/branch strings, should we pull that fix to the rpm specfile? https://github.com/MythTV/packaging/pull/35 |
| [06:47:48] | dekarl: | stuartm, can you close this one https://github.com/MythTV/packaging/pull/38 as per the OP's request? |
| [06:48:33] | dekarl: | and close https://github.com/MythTV/packaging/pull/39, please. It is in, including the last commit |
| [08:12:27] | Merlin83b (Merlin83b!~Daniel@office.34sp.com) has joined #mythtv | |
| [08:46:44] | joki (joki!~joki@p5486164C.dip0.t-ipconnect.de) has quit (Ping timeout: 260 seconds) | |
| [08:50:22] | Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has joined #mythtv | |
| [08:51:51] | joki (joki!~joki@p54862E3D.dip0.t-ipconnect.de) has joined #mythtv | |
| [09:05:13] | MythBuild: | build #2378 of master-debian-wheezy-64bit is complete: Failure [4failed git] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2378 blamelist: Stuart Morgan <smorgan@mythtv.org > |
| [09:05:35] | MythBuild: | build #2066 of master-ubuntu-12_04-lts-64bit is complete: Failure [4failed git] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2066 blamelist: Stuart Morgan <smorgan@mythtv.org > |
| [09:06:03] | MythBuild: | build #36 of master-centos7–64bit is complete: Failure [4failed git] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . it/builds/36 blamelist: Stuart Morgan <smorgan@mythtv.org > |
| [09:11:05] | stuarta: | pardon? |
| [09:14:19] | stuarta: | i really need to look at if it can auto retry on a failed git step |
| [09:37:21] | stuartm: | dekarl: #35 looks correct |
| [09:37:21] | ** MythLogBot http://code.mythtv.org/trac/ticket/35 ** | |
| [09:38:17] | stuartm: | for exported sources we need to use EXPORTED_VERSION, as VERSION is only valid after compilation on unexported sources |
| [09:39:45] | MythBuild: | build #37 of master-centos7–64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . it/builds/37 |
| [09:41:42] | MythBuild: | build #2379 of master-debian-wheezy-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2379 |
| [09:41:58] | MythBuild: | build #2067 of master-ubuntu-12_04-lts-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2067 |
| [09:44:22] | jpharvey_ (jpharvey_!~jpharvey@host109-148-239-15.range109-148.btcentralplus.com) has quit (Ping timeout: 240 seconds) | |
| [09:56:49] | jpharvey_ (jpharvey_!~jpharvey@host109-148-238-63.range109-148.btcentralplus.com) has joined #mythtv | |
| [10:42:15] | stuartm: | jpabq: coverity is complaining about a null check added in august to ExternalStreamHandler, "check_after_deref: Null-checking this->m_IO suggests that it may be null, but it has already been dereferenced on all paths leading to the check." |
| [10:43:41] | stuartm: | and I'd have to agree on this occassion that it doesn't seem possible for it to be null at that point, without it also being possibly null at two further locations before then, – the while() condition and the first if() just after we enter the while loop |
| [10:44:05] | stuartm: | sorry, this is line 602 |
| [10:44:43] | stuartm: | I'm just not sure what to do there given the commit which added that check suggested it fixed a segfault? |
| [10:46:48] | jnylen (jnylen!~jnylen@unaffiliated/jnylen) has quit (Ping timeout: 250 seconds) | |
| [10:46:57] | _charly_ (_charly_!~kroseneg@v-83-246-40-180.eu.hostway-enterprise.net) has quit (Quit: _charly_) | |
| [10:47:26] | jnylen (jnylen!~jnylen@unaffiliated/jnylen) has joined #mythtv | |
| [10:48:05] | _charly_ (_charly_!~kroseneg@v-83-246-40-180.eu.hostway-enterprise.net) has joined #mythtv | |
| [11:57:00] | gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has quit (Quit: Leaving) | |
| [12:50:54] | sheedy-away is now known as sheedy | |
| [12:58:33] | andreaz (andreaz!~Andreaz@tmo-097-189.customers.d1-online.com) has joined #mythtv | |
| [13:19:53] | stuartm: | android doesn't like self-signed certificates, now of the opinion that android sucks :) |
| [13:46:10] | stuarta: | i'm at that great dilemma in life. which phone do i get next.... |
| [13:46:37] | dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip.81.200.198.20) has joined #mythtv | |
| [13:53:34] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has quit (Ping timeout: 260 seconds) | |
| [13:54:01] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has joined #mythtv | |
| [13:57:30] | dekarl-work: | stuartm, you have to rub harder. Its only snake oil after all... |
| [13:58:03] | dekarl-work: | looks like you can install your signing cert as trusted cert manually |
| [13:58:21] | stuartm: | dekarl-work: tried that, couldn't get it to work |
| [13:58:50] | stuartm: | and besides, it's a bit much to expect MythTV users to do that just to get a secure connection to their MythTV box |
| [14:01:05] | stuartm: | wonder if iOS has the same problem |
| [14:01:37] | dekarl-work: | hmm, google hints that you can just direct them to the certificate on the internal webserver and let them click "install this certificate" somehow. But the details are not so clear |
| [14:08:04] | dekarl-work: | random link via google: http://forum.xda-developers.com/showpost.php? . . . ;postcount=6 |
| [14:13:48] | stuartm: | further down that same thread it indicates that it only works for 'Browser', not Chrome, Opera or Firefox on android |
| [14:18:36] | stuartm: | 'Browser' on my tablet (not available on my phone) gives a 'No certificate to install' error |
| [14:20:21] | stuartm: | although you apparently need to get the headers right ... meh, will play with it later |
| [14:26:20] | dekarl1 (dekarl1!~dekarl@p4FE844C6.dip0.t-ipconnect.de) has joined #mythtv | |
| [14:27:11] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has joined #mythtv | |
| [14:28:15] | dekarl (dekarl!~dekarl@p4FE84DB0.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds) | |
| [14:35:08] | stuartm: | got the 'install from browser' bit to work, but it still fails to load the site |
| [14:54:15] | stuartm: | wagnerrp: https://github.com/MythTV/mythtv/pull/69 |
| [15:00:19] | sheedy is now known as sheedy-away | |
| [15:06:14] | dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip.81.200.198.20) has quit () | |
| [15:17:40] | FabriceMG (FabriceMG!~Thunderbi@LCaen-656-01-100-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG) | |
| [16:16:12] | natanojl (natanojl!~jonatan@c83-252-231-38.bredband.comhem.se) has joined #mythtv | |
| [16:24:00] | dekarl1 is now known as dekarl | |
| [16:40:42] | Chutt (Chutt!~ijr@cpe-174-100-158-24.neo.res.rr.com) has quit (Ping timeout: 245 seconds) | |
| [16:47:58] | ** stuarta plays with git bisect ** | |
| [16:51:09] | XDS2010___ is now known as XDS2010 | |
| [17:07:19] | Chutt (Chutt!~ijr@cpe-174-100-158-24.neo.res.rr.com) has joined #mythtv | |
| [17:18:05] | stuarta: | stuartm: i'm beginning to suspect i was dreaming and upnp-inspector never saw both backends |
| [17:18:07] | Merlin83b (Merlin83b!~Daniel@office.34sp.com) has quit (Quit: Leaving) | |
| [17:18:21] | stuarta: | doing some bisection and not had the result i was anticipating |
| [17:20:11] | stuartm: | stuarta: I'd struggle to explain why it's working here, but not for you, I'm using the latest version from git fwiw |
| [17:21:31] | stuartm: | and I had to apply this patch to the installed coherence libs – https://github.com/coherence-project/Coherenc . . . 2a73f62e3727 |
| [17:27:12] | andreaz (andreaz!~Andreaz@tmo-097-189.customers.d1-online.com) has quit (Ping timeout: 250 seconds) | |
| [17:27:14] | andreaz1 (andreaz1!~Andreaz@tmo-097-189.customers.d1-online.com) has joined #mythtv | |
| [17:27:17] | gigem (gigem!~david@mythtv/developer/gigem) has quit (Ping timeout: 245 seconds) | |
| [17:27:18] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 260 seconds) | |
| [17:28:09] | dekarl (dekarl!~dekarl@p4FE844C6.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds) | |
| [17:28:37] | dekarl (dekarl!~dekarl@p4FE844C6.dip0.t-ipconnect.de) has joined #mythtv | |
| [17:29:40] | aloril (aloril!~aloril@dsl-tkubrasgw2-54faa3-2.dhcp.inet.fi) has quit (Ping timeout: 272 seconds) | |
| [17:29:49] | stuarta: | stuartm: i'll play some more. upnp-inspector clearly doesn't like my setup. |
| [17:30:56] | gigem (gigem!~david@pool-71-170-165-247.dllstx.fios.verizon.net) has joined #mythtv | |
| [17:30:56] | gigem (gigem!~david@pool-71-170-165-247.dllstx.fios.verizon.net) has quit (Changing host) | |
| [17:30:56] | gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv | |
| [17:33:10] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [17:34:57] | SteveGoodey (SteveGoodey!~steve@host86-164-55-181.range86-164.btcentralplus.com) has joined #mythtv | |
| [17:35:03] | aloril (aloril!~aloril@dsl-tkubrasgw2-54faa3-2.dhcp.inet.fi) has joined #mythtv | |
| [18:06:05] | andreaz1 (andreaz1!~Andreaz@tmo-097-189.customers.d1-online.com) has quit (Read error: Connection reset by peer) | |
| [18:18:01] | jpharvey (jpharvey!~jpharvey@host86-181-25-182.range86-181.btcentralplus.com) has joined #mythtv | |
| [18:21:02] | jpharvey_ (jpharvey_!~jpharvey@host109-148-238-63.range109-148.btcentralplus.com) has quit (Ping timeout: 245 seconds) | |
| [18:33:31] | dekarl: | stuartm, please close https://github.com/MythTV/packaging/pull/35 |
| [18:35:09] | stuartm: | done |
| [18:35:53] | dekarl: | hmm, re https://github.com/MythTV/packaging/pull/25 jya said in https://code.mythtv.org/trac/ticket/10881 that it doesn't apply anymore. so just close that one, too? |
| [18:36:37] | dekarl: | I found that by following the tickets referred to in the pull request which have all been closed as duplicate of #10881 (which actually talks about another pull request) |
| [18:36:37] | ** MythLogBot http://code.mythtv.org/trac/ticket/10881 ** | |
| [18:38:41] | dekarl: | I think I'll go to the extreme and just ask the OK ;) |
| [18:38:46] | dekarl: | s/OK/OP/ |
| [18:40:00] | stuartm: | dekarl: I see mention of python and I just zone out, if you or wagnerrp think those patches are not required I'll just close :) |
| [18:42:12] | dekarl: | The only Python I know about is the one that swallowed the aligator. |
| [18:44:25] | dekarl: | This Gentoo packaging fix is about git pull --rebase instead of a plain pull. Does it make sense to automatically do that? I'd expect starting from scratch instead. https://github.com/MythTV/packaging/pull/22 |
| [18:45:38] | dekarl: | tgm4883: superm1: can you comment on that deb pull request, has this been superseded or are there pieces that are still useful? https://github.com/MythTV/packaging/pull/27 |
| [18:45:54] | stuarta: | stuartm: so i've detected a few differences that may cause issues |
| [18:46:24] | tgm4883: | dekarl: I believe it's superseded, but I'll wait for superm1 to comment |
| [18:46:33] | superm1: | i think superseded too |
| [18:46:38] | stuarta: | 1. we are advertising localhost ipv4 (127.0.0.1) ipv6 (::1) |
| [18:47:02] | stuarta: | 2. the link local ipv6 address is advertised with the scope relative to the backend |
| [18:47:18] | stuarta: | back later to fiddle some more |
| [18:51:22] | stuartm: | dekarl: I can find my way around in python if I need to, but it's easier for me to say that anything not C/C++ is someone else's department, if I didn't then I'd just never get anything done at all |
| [18:52:25] | dekarl: | stuartm, looks like this one is superseded and can be closed https://github.com/MythTV/packaging/pull/27 |
| [18:55:08] | stuartm: | stuarta: I'm still as clueless about IPv6 as I ever was |
| [18:56:39] | dekarl: | I don't understand what this one is about and its full of unrelated stuff. Is that just to update fixes/0.25 to a newer fixes/0.25? I'd say just close it as superseded then https://github.com/MythTV/packaging/pull/28 |
| [18:57:40] | stuartm: | stuarta: we don't actually include the IP is the SSDP announcement, rather the client looks at the IP it received the announcement from – so we send out the exact same announcement on loopback and each of the interfaces |
| [18:59:46] | stuartm: | the client receives 1 or 2 or more identical announcements, each on a socket with a different peer IP, the client recognises each one as the same server available on multiple IPs and picks which address it prefers to use for communication |
| [19:01:05] | stuartm: | because we use multicast, only a client on the same machine as the server would receive an announcement from the IPv4 loopback – not so sure about the IPv6 case though |
| [19:01:54] | dekarl: | looks like these updates to gentoo packaging for fixes/0.26 – https://github.com/MythTV/packaging/pull/32 and the other one to fixes/0.27 and master – https://github.com/MythTV/packaging/pull/33 do still apply. wagnerrp should these be merged? I see the last update to gentoo packaging was before these pull requests |
| [19:06:06] | dekarl: | stuartm, this one was rejected by wagnerrp on the ticket, but left open. can you close it? https://github.com/MythTV/mythweb/pull/6 |
| [19:06:43] | dekarl: | stuartm, kormoc reported on this one that its fixed. please close it, too. https://github.com/MythTV/mythweb/pull/8 |
| [19:08:09] | dekarl: | just 20 pull requests in the main repo to go, leaving that for another night |
| [19:18:12] | dekarl: | stuartm, should we close https://github.com/MythTV/mythtv/pull/81 in favour of https://github.com/MythTV/mythtv/pull/70? I think using the service api for to get the cutlist with byte ranges and then the backend webserver to get the file with byte range requests sounds sane. |
| [19:29:04] | stuartm: | dekarl: well for our purposes the internal protocol is still king, it's not that we can't transition to using the services API internally, but we just don't have the framework currently |
| [19:29:36] | stuartm: | for that reason I still think 81 is worth merging, it gets us away from direct DB access which is good |
| [19:30:02] | stuartm: | and for services clients I'd merge 70 too |
| [19:32:30] | stuartm: | JanBar has a point about the buffering, it takes longer to fetch a byte range over http because we have to keep opening the file, seeking, reading etc, with the internal protocol the file is left open as long as the client is playing and we just read out the next X bytes without having to seek each time |
| [19:33:39] | stuartm: | that means the client can get away with smaller buffers, http requires the client to buffer more, which requires more memory |
| [19:34:24] | stuartm: | that said, it doesn't seem to pose a problem for embedded upnp clients |
| [19:35:47] | stuartm: | and potentially we can improve the response times with some refactoring, so that we keep the file open as long as the connection stays open to avoid the open, seek, read, close, open, seek, read [...] overhead |
| [19:40:27] | stuartm: | actually, I like that idea so much it's going on my 'most wanted' todo list |
| [19:45:34] | stuartm: | just as soon as I remember where I left my notebook |
| [19:48:46] | stuarta: | stuartm: i have a packet capture that shows we are sending an announcement for every ip address on the system. loopback, ipv4 and ipv6 |
| [19:49:03] | stuartm: | correct |
| [19:49:51] | stuarta: | well that's alright then ;-p |
| [19:51:09] | ** stuarta wanders off again ** | |
| [19:53:36] | stuartm: | as I mentioned earlier, that's the intended behaviour, we send announcements on all addresses (interfaces), the client receives one or all of those and selects which one is most suitable to respond on |
| [19:55:09] | stuartm: | I'm not sure how well upnp clients will handle IPv6, it's still not officially part of the UPnP spec (I believe), so I'd expect most of them to ignore IPv6 addresses and go with the IPv4 address |
| [19:57:23] | stuartm: | I'm running upnp inspector on the same machine here, so it's using 127.0.0.1 |
| [19:57:59] | stuartm: | it shouldn't even receive the 127.0.0.1 announcement if I was running it on another machine |
| [19:59:17] | kormoc: | there's a open bug with myth web being given a loop back address from a remote backend |
| [19:59:23] | kormoc: | that shouldn't happen, or it should? |
| [20:00:19] | stuartm: | shouldn't happen for upnp, might happen for the internal protocol if you configure the master backend to listen on the 127.0.0.1 address instead of an external IP |
| [20:05:15] | stuartm: | I believe I'm right in asserting that the backend does not specify the IP address in the SSDP announcement, instead that's conveyed at the TCP socket level, since it's impossible for an announcement to be sent on 127.0.0.1 to be received by a remote client it should be impossible for a upnp client to see that address |
| [20:05:53] | stuarta: | i disagree |
| [20:06:59] | stuarta: | the announcement's are all coming from the main ipv4 address (192.168.10.1), but are announcing all other possibilities including 127.0.0.1 in the LOCATION upnp header |
| [20:08:22] | stuarta: | http://fpaste.org/134034/14108980/ |
| [20:11:50] | stuartm: | stuarta: yeah, I see that now (opened up the code a moment ago to take a look) |
| [20:12:43] | stuartm: | hmm |
| [20:12:52] | stuarta: | apologies for whacking you with tcpdumps. my day job often involves disproving what other people consider facts |
| [20:12:57] | stuartm: | and it's UDP |
| [20:13:07] | stuarta: | aye it is |
| [20:13:07] | stuartm: | not TCP as I suggested earlier :/ |
| [20:13:22] | stuarta: | udp is correct for this |
| [20:13:42] | stuarta: | found a good page on upnp earlier http://www.mythtv.org/wiki/UPnP :) |
| [20:13:48] | stuarta: | 2nd hit on google too |
| [20:14:55] | stuartm: | well that's not quite right then, I guess I was making assumptions based on what I'd read in the upnp documentation, but it seems we're taking a shortcut in our implementation |
| [20:15:04] | stuarta: | oops |
| [20:16:41] | dekarl: | stuartm, sounds nice. IIUIC the partial file streaming via http is also the way to go to implement the cutlist for upnp? (basically serving a playlist with the uncut parts instead of the real file) But then I have no idea how these playlists can refer to partial files |
| [20:17:25] | stuarta: | dekarl: same way a dvd contains chapters. essentially it's really just a list of blocks that belong to a given chapter |
| [20:18:37] | stuartm: | dekarl: theoretically I suppose, the upnp client would be completely oblivious, the backend would have to adjust the requested byte range to an 'actual' byte range after adjusting for the cutlist |
| [20:18:55] | stuartm: | but I don't know whether the upnp client would tolerate the discontinuity |
| [20:20:42] | stuartm: | latest upnp allows for DASH streaming (transcoding to 'segments') and I think that would be the way to go if we want to support cutlists, since implementing cutlist support for DASH would also work for streaming to an HTML 5 video player |
| [20:21:09] | stuartm: | it would rule out older upnp clients though |
| [20:21:37] | stuartm: | (from using cutlists, not from playing back files) |
| [20:22:26] | dekarl: | hmm, maybe the dlna people can bribe you to implement it as an incentive for others to upgrade their clients to post-2000 specs :-D |
| [20:23:32] | stuartm: | will definitely be implementing DASH, especially since jya is now working for Mozilla to implement DASH support in Firefox :) |
| [20:24:12] | stuartm: | stuarta: let me give the SSDP stuff some thought |
| [20:24:39] | stuarta: | stuartm: yeah no problems, there's no rush on my side |
| [20:24:56] | ** stuarta is trying to prepare for 3 back to back meetings tomorrw ** | |
| [20:26:30] | dekarl: | did I understand that correctly that there is a page like this for DLNA, too? http://upnp.org/sdcps-and-certification/standards/sdcps/ |
| [20:45:26] | SteveGoodey (SteveGoodey!~steve@host86-164-55-181.range86-164.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [20:50:36] | cotterpin (cotterpin!~hp-mini@119.224.77.140) has joined #mythtv | |
| [20:52:19] | cotterpin: | dekarl: the serviceID 999 clipping (you mentioned) comes from https://github.com/MythTV/mythtv/blob/master/ . . . ngs.cpp#L309 |
| [20:53:22] | stuarta: | whoops, that's a simple patch for anyone to fix |
| [20:53:56] | dekarl: | cotterpin: I mentioned it? well, I see #12273 |
| [20:53:56] | ** MythLogBot http://code.mythtv.org/trac/ticket/12273 ** | |
| [20:54:19] | stuarta: | s/999/65535/ job done |
| [20:54:34] | cotterpin: | dekarl: some days ago.. |
| [20:54:51] | stuarta: | well assuming serviceid's are 16bit, my memory is rusty |
| [20:55:06] | dekarl: | either way, good catch. I couldn't find it in the code when I looked at that ticket |
| [20:56:23] | cotterpin: | I spent several weeks trying to find the source of the 999, this morning found it in 10mins. |
| [20:56:39] | stuarta: | stuartm: btw. bubble upnp doesn't care, seems on upnp-inspector does |
| [20:58:46] | stuarta: | er only |
| [21:09:48] | cotterpin (cotterpin!~hp-mini@119.224.77.140) has left #mythtv () | |
| [21:12:39] | stuartm: | dekarl: with the specs? Not exactly, there's a page where you enter your details and in return you get access to them |
| [21:12:54] | stuartm: | I can email you copies though |
| [21:13:00] | natanojl (natanojl!~jonatan@c83-252-231-38.bredband.comhem.se) has quit (Ping timeout: 272 seconds) | |
| [21:14:35] | dekarl: | stuartm, I was trying to look at the "playlist" spec to see if you can signal parts of files as item |
| [21:15:22] | dekarl: | we should just drop the pointer at the best hit for upnp ;) http://www.mythtv.org/wiki/UPnP |
| [21:18:10] | stuartm: | dekarl: not sure exactly which feature you're referring to but for upnp itself the stuff concerning MythTV is mostly in http://upnp.org/specs/av/UPnP-av-ContentDirectory-v4-Service.pdf |
| [21:18:49] | ** stuarta downloads ** | |
| [21:18:57] | stuartm: | to get the DLNA guidelines – http://www.dlna.org/dlna-for-industry/guidelines |
| [21:19:16] | dekarl: | stuartm, I was wondering if it is actually possible to just drop a file on a http server and tell the UPNP client to only play a part (byte range) of it |
| [21:22:04] | stuartm: | dekarl: no, that's not part of the spec so far as I'm aware, but you could do it by giving the client a special URL that only returns part of the file |
| [21:23:27] | stuartm: | i.e. if you tell the upnp client that the stream is at the following url /Content/GetRecording?Start=1234&End=6789 it's not going to know or care that it's only getting part of the total file |
| [21:24:07] | stuartm: | however it will treat that as the entire file, there's no option to say that a single video is made up of a sequence of segments |
| [21:24:27] | stuartm: | except for DASH, but that's something very different |
| [21:24:47] | stuarta: | damn, i thought reading rfc's was boring, but those upnp specs are worse |
| [21:25:00] | stuartm: | stuarta: it's hard going at times |
| [21:25:11] | dekarl: | ok, so http + byte ranges would be for custom mythtv clients using the service api + http transfer only |
| [21:25:21] | dekarl: | stuarta, amen |
| [21:25:22] | stuartm: | DLNA specs are even worse |
| [21:25:39] | ** stuarta falls asleep ** | |
| [21:25:58] | stuarta: | sheesh i prefer reading hexdumps and packet captures to that lot |
| [21:26:03] | dekarl: | "are you still counting sheep or reading specifications written by a committee already?" |
| [21:26:18] | stuarta: | not a lot of difference |
| [21:26:35] | stuartm: | dekarl: most upnp clients will use byte ranges over http, but not to skip sections, just to facilitate streaming and seeking with small client buffers |
| [21:27:27] | stuartm: | stuarta: secret is not to read it from start to finish, but to skip around to the interesting bits, assuming you can work out what those are ;) |
| [21:27:53] | stuarta: | yeah there were one or two of those in the contents, then i died of boredom trying to skip to them |
| [21:28:02] | stuartm: | this is the service I want to implement next – http://upnp.org/specs/av/UPnP-av-ScheduledRec . . . -Service.pdf |
| [21:28:45] | stuartm: | will allow any upnp client that supports it to schedule recordings |
| [21:29:56] | stuartm: | there are also the AVTransport and RenderingControl services which would let client control playback on the frontend (remote control stuff basically) |
| [21:30:47] | stuartm: | dekarl: bookmark support is possible, UPnP covers that much |
| [21:32:14] | dekarl: | stuartm: I saw something like that pass by on a commit IIRC, sounded nice. pushing up the mythical "begin of program" bookmark one spot |
| [21:32:47] | dekarl: | but could default to the end of the first cut, if it starts at the beginning of the recording, too |
| [21:33:25] | dekarl: | That should be enough to allow watching recordings from commercial free via UPNP without having to hunt the beginning on the UPNP client every time |
| [21:44:32] | gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has joined #mythtv | |
| [21:50:36] | jpharvey (jpharvey!~jpharvey@host86-181-25-182.range86-181.btcentralplus.com) has quit (Ping timeout: 272 seconds) | |
| [21:58:18] | sheedy-away is now known as sheedy | |
| [22:03:03] | jpharvey (jpharvey!~jpharvey@host86-181-25-182.range86-181.btcentralplus.com) has joined #mythtv | |
| [22:28:17] | Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
| [22:42:13] | gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [22:45:15] | dekarl (dekarl!~dekarl@p4FE844C6.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds) | |
| [23:04:28] | gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has joined #mythtv | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.