Beirdobot, irc.freenode.net

Thursday, January 8th, 2015, 00:00 UTC

[00:00:06]

stuartm:

actually, if anyone with an HDHR could pastebin the results of the above it would help

[00:09:54]

dym:

sec

[00:11:00]

dym:

stuartm: empty set

[00:12:48]

stuartm:

dym: ok, just to confirm – SELECT id, name from profilegroups;

[00:13:03]

stuartm:

13 should be "HDHomeRun Recorders"

[00:13:18]

tgm4883:

dekarl: what do you mean?

[00:13:42]

dym:

http://pastebin.com/4fsBRVdU

[00:13:44]

tgm4883:

dekarl: and actually, we do have a "latest fixes or master, but with a Patch PPA builder". It's not automated, but it's easy to do

[00:13:51]

dym:

stuartm: it's not

[00:13:55]

stuartm:

if so that rules out the pid filtering change as it would appear to default to keeping all streams for HDHR devices

[00:14:19]

stuartm:

dym: interesting, I thought those were meant to be static

[00:14:39]

stuartm:

dym: ok, replace 13 in the first statement with 11

[00:14:53]

dym:

empty set

[00:15:36]

dekarl:

tgm4883: if we move (break/replace) the fixes/0.27 packages older then today, then we should do the same for master. At least that was my thought

[00:15:53]

Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has quit (Ping timeout: 240 seconds)

[00:16:07]

dekarl:

s/move/move out of the way/

[00:16:21]

tgm4883:

dekarl: yes. I thought both of those pull requests covered that

[00:16:40]

dym:

stuartm: what does that mean?

[00:17:34]

dekarl:

hmm, because 0.27.0+master is less the 0.27.4+fixes?

[00:18:00]

tgm4883:

Or wait

[00:18:03]

stuartm:

dym: it means I really don't have a clue what is causing the issue you're experiencing, there are no changes in MythTV between 0.27.0 and 0.27.4 which could be related

[00:18:24]

dekarl:

tgm4883: the version strings are confusing for me. past 1am, time to hit sack ;)

[00:18:39]

stuartm:

damn, looks like the profile groups are all fucked up – "HDHomeRunGroup = 13,"

[00:18:41]

stuartm:

"INSERT INTO profilegroups VALUES (11,'HDHomeRun Recorders','HDHOMERUN',1,NULL);",

[00:19:11]

stuartm:

I don't know how we even start to unravel that screwup

[00:19:39]

tgm4883:

dekarl: yea now that I think about it, the master branch packaging is wrong. I should be breaking 0.28, not 0.27

[00:19:43]

tgm4883:

let me fix that

[00:20:04]

dym:

mhh

[00:20:22]

dekarl:

tgm4883: you might want to update the version from master/0.27 to master/0.28 while at it ;)

[00:20:51]

Hydroponx (Hydroponx!~hydr@71-12-104-200.dhcp.mtgm.al.charter.com) has joined #mythtv

[00:21:45]

Hydr0p0nX (Hydr0p0nX!~hydr@71-12-104-200.dhcp.mtgm.al.charter.com) has quit (Disconnected by services)

[00:21:56]

dekarl:

tgm4883: I vaguely remember talking to you/sup erm1 about the concept of such a "hosted patch ppa builder" so non-ubuntu devs can prepare packages for users to test stuff. But that was some time ago.

[00:22:01]

Hydroponx is now known as Hydr0p0nX

[00:22:23]

Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has joined #mythtv

[00:22:34]

tgm4883:

dekarl: I'm wondering if it would be possible to do it as a branch on github?

[00:22:47]

tgm4883:

dekarl: so like fixes/0.27+patch or something like that

[00:22:58]

tgm4883:

then we could possibly automate it like we do the dailies

[00:23:01]

dekarl:

hmm

[00:23:17]

stuartm:

https://github.com/MythTV/mythtv/commit/456caa89 https://github.com/MythTV/mythtv/commit/10c6d570

[00:23:25]

dekarl:

that would fit well with github forks/branches and pull requests

[00:23:33]

stuartm:

sphery_: might need some help fixing this

[00:23:35]

tgm4883:

our goal is to have things as automated as possible

[00:24:06]

tgm4883:

dekarl: do you mean have pull requests on github automatically built?

[00:24:07]

dekarl:

sounds good. We could run a buildbot for these, too. (changes that have not yet been commited to master)

[00:24:13]

dekarl:

tgm4883: yes

[00:24:35]

tgm4883:

dekarl: I'll look into that, not sure it's as easy as just pulling the latest from some branch

[00:25:57]

dekarl:

tgm4883: see https://github.com/blog/1935-see-results-from . . . tatus-checks for an idea how a pull requests could look like with all kinds of automated tests

[00:27:04]

superm1:

dekarl: buildbot with saving artifacts might be easier

[00:27:20]

superm1:

so we don't have to reinvent the wheel in shell scripting to manage this

[00:27:43]

dekarl:

and this would be a buildbot scheduler for stuff outside of the repo http://docs.buildbot.net/0.8.4p2/Try-Schedulers.html

[00:28:24]

dym:

okay, pre-upgrade machine is up and configured – testing now.

[00:28:31]

dekarl:

superm1: like a packaging/deb buildbot?

[00:28:58]

superm1:

dekarl: yeah

[00:29:04]

superm1:

it should be scriptable to do i thinks

[00:29:24]

dekarl:

actually that would be a nice thing, build the packages on Ubuntu LTS / Debian and see if it works, so all devs can catch forgotting stuff, like added executeables

[00:29:46]

dekarl:

without having to find the information hidden deep in launchpad

[00:29:51]

superm1:

yeah

[00:29:55]

tgm4883:

ok, so I'm going to go back to fixing the master packaging

[00:30:44]

dym:

ok

[00:30:48]

dym:

you're not going to like this

[00:30:57]

dym:

MythBuntu standard installation: flawless tv playback

[00:33:33]

tgm4883:

dym: that sounds good to me :)

[00:34:02]

dym:

tgm4883: well, dekarl suggested that the updates provided a lot of livetv improvements :D

[00:34:10]

dym:

channel switchting, etc :D

[00:34:46]

tgm4883:

dym: oh, I was just saying that "flawless tv playback" sounds good. I didn't read any of the backlog

[00:34:52]

dym:

:)

[00:35:09]

dekarl:

sounds like all the nice improvements for LiveTV come with a regression around the HDHR :/

[00:37:01]

dym:

very much so

[00:38:31]

tgm4883:

dekarl: https://github.com/MythTV/packaging/pull/44 should fix the master packaging

[00:38:37]

dekarl:

oh my, found the HLS regression... we don't leave the segment URL alone, but instead convert %2F (as its in the variant playlist) back to "/", thus getting a 404

[00:38:51]

dekarl:

anybody got an idea where to fix that?

[00:40:05]

tgm4883:

stuartm: do you still want dym to test that patch?

[00:43:31]

stuartm:

tgm4883: doesn't look like it would affect him, so no

[00:43:39]

tgm4883:

ok

[00:43:46]

tgm4883:

i won't build it then

[00:45:07]

stuartm:

dekarl: no idea, but it sounds like another case where we're using strings to pass urls around instead of using QUrl – that sort of breakage is typical and avoidable

[00:49:21]

dekarl:

stuartm, time to hit sack. I opened a ticket so I will remember what it was tomorrow ;)

[00:50:44]

stuartm:

just done the same for the issue I ran across

[00:50:55]

** stuartm is off to bed **

[00:59:12]

** dym is off too **

[01:02:27]

moparisthebest (moparisthebest!~mitb@unaffiliated/moparisthebest) has quit (Ping timeout: 264 seconds)

[01:10:01]

Hydr0p0nX (Hydr0p0nX!~hydr@71-12-104-200.dhcp.mtgm.al.charter.com) has quit (Ping timeout: 244 seconds)

[01:11:08]

moparisthebest (moparisthebest!~mitb@unaffiliated/moparisthebest) has joined #mythtv

[01:11:40]

Hydr0p0nX (Hydr0p0nX!~hydr@71-12-104-200.dhcp.mtgm.al.charter.com) has joined #mythtv

[01:45:29]

andreaz (andreaz!~andre_000@p5DD14ABE.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer)

[01:59:56]

Hydr0p0nX (Hydr0p0nX!~hydr@71-12-104-200.dhcp.mtgm.al.charter.com) has quit (Ping timeout: 244 seconds)

[02:30:56]

Hydr0p0nX (Hydr0p0nX!~hydr@71-12-104-200.dhcp.mtgm.al.charter.com) has joined #mythtv

[02:40:34]

amessina (amessina!~amessina@unaffiliated/amessina) has quit (Remote host closed the connection)

[03:01:56]

amessina (amessina!~amessina@unaffiliated/amessina) has joined #mythtv

[03:29:49]

sleezio (sleezio!~slee@unaffiliated/sleezio) has joined #mythtv

[03:30:16]

sleezio:

hello, does titantv still provide their EPG/XML service for channel lineup to use with mythweb?

[03:31:25]

sleezio:

i found their dataservice page, but it asumes you already have a key(UUID), but i can't find where to signup for the key: http://data.titantv.com/dataservice.asmx

[03:31:46]

sleezio:

oops, sorry, i see i'm on the wrong channel

[03:38:37]

peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 244 seconds)

[03:39:40]

peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv

[03:51:52]

sleezio (sleezio!~slee@unaffiliated/sleezio) has quit (Quit: mmmm....bacon)

[03:56:03]

gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has quit (Ping timeout: 264 seconds)

[03:58:06]

arescorpio (arescorpio!~arescorpi@217-57-245-190.fibertel.com.ar) has quit (Excess Flood)

[03:58:51]

Hydroponx (Hydroponx!~hydr@71-12-104-200.dhcp.mtgm.al.charter.com) has joined #mythtv

[04:00:39]

Hydr0p0nX (Hydr0p0nX!~hydr@71-12-104-200.dhcp.mtgm.al.charter.com) has quit (Ping timeout: 264 seconds)

[04:09:06]

gregL (gregL!~greg@173-198-250-23.static.as40244.net) has joined #mythtv

[04:18:10]

sheedy is now known as sheedy-away

[04:33:33]

gregL (gregL!~greg@173-198-250-23.static.as40244.net) has quit (Ping timeout: 265 seconds)

[04:43:45]

fetzerch_ (fetzerch_!~quassel@unaffiliated/fetzerch) has joined #mythtv

[04:47:47]

fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 245 seconds)

[04:51:27]

gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has joined #mythtv

[05:46:37]

poptix- (poptix-!poptix@poptix.net) has joined #mythtv

[05:46:49]

poptix (poptix!poptix@poptix.net) has quit (Read error: Connection reset by peer)

[06:23:57]

amessina (amessina!~amessina@unaffiliated/amessina) has quit (Ping timeout: 244 seconds)

[06:27:34]

gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Ping timeout: 244 seconds)

[06:41:02]

gigem_ (gigem_!~david@pool-71-170-165-247.dllstx.fios.verizon.net) has joined #mythtv

[06:41:02]

gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv

[06:41:02]

gigem_ (gigem_!~david@pool-71-170-165-247.dllstx.fios.verizon.net) has quit (Changing host)

[07:07:05]

brfransen (brfransen!~brfransen@24-197-128-95.dhcp.spbg.sc.charter.com) has quit (Read error: Connection reset by peer)

[07:07:58]

brfransen (brfransen!~brfransen@24-197-128-95.dhcp.spbg.sc.charter.com) has joined #mythtv

[07:08:28]

FabriceMG (FabriceMG!~Thunderbi@LCaen-656-1-100-212.w80-11.abo.wanadoo.fr) has joined #mythtv

[07:17:47]

SteveGoodey (SteveGoodey!~steve@host109-158-208-74.range109-158.btcentralplus.com) has joined #mythtv

[07:20:12]

SteveGoodey (SteveGoodey!~steve@host109-158-208-74.range109-158.btcentralplus.com) has quit (Client Quit)

[07:38:04]

Roklobsta (Roklobsta!~Roklobsta@ppp118-209-54-69.lns20.mel4.internode.on.net) has joined #mythtv

[07:51:46]

Tobbe5178 (Tobbe5178!~asdf@2001:2002:d9d4:ce7e:4d05:ed1a:68da:59bf) has joined #mythtv

[08:07:11]

Tobbe5178 (Tobbe5178!~asdf@2001:2002:d9d4:ce7e:4d05:ed1a:68da:59bf) has quit (Ping timeout: 265 seconds)

[08:07:38]

Tobbe5178 (Tobbe5178!~asdf@2001:2002:d9d4:ce7e:8512:39a0:3dc6:7966) has joined #mythtv

[08:37:37]

Roklobsta (Roklobsta!~Roklobsta@ppp118-209-54-69.lns20.mel4.internode.on.net) has quit (Ping timeout: 264 seconds)

[08:48:36]

Roklobsta (Roklobsta!~Roklobsta@ppp118-209-54-69.lns20.mel4.internode.on.net) has joined #mythtv

[09:18:07]

peper03:

stuartm: Just scanning over the logs. PID filtering is not currently under suspicion, right? I'll admit I don't understand all the ins and outs of MPEG processing but I'd be surprised if filtering the PCR would cause parsing errors on the backend. It's only needed for playback, right?

[09:19:23]

peper03:

Also, if I remember correctly, we only filter if the user has explicitly changed the setting. It defaults to 'no filtering'.

[09:43:35]

stuartm:

peper03: it's been ruled out, although the problem was playback errors

[09:44:14]

stuarta:

did we verify playback of recordings from before and after the upgrade?

[09:44:23]

stuartm:

I may still commit something to ensure that we don't ever remove the stream containing the PCR data

[09:44:37]

dym:

okay, this is laughable. today also the mythbuntu installation shows the reception errors.

[09:44:40]

dym:

morning guys.

[09:44:55]

dym:

talking about the unmodified mythbuntu

[09:46:08]

dym:

http://www.xstd.de/mythbackend-noupdates.txt

[09:52:09]

stuarta:

this the original 0.27 that comes with mythbuntu?

[09:54:10]

stuarta:

i should just look at the backend log, that'll answer my question

[09:55:32]

stuarta:

mythbackend version: fixes/0.27 [v0.27-193-g8ee257c]

[09:55:49]

Merlin83b (Merlin83b!~Daniel@office.34sp.com) has joined #mythtv

[10:02:15]

dym:

stuarta: this is the original mythbuntu version

[10:11:57]

stuarta:

in that case it rules out that the mythtv upgrade caused it.

[10:12:38]

len__ (len__!~quassel@75-168-45-25.mpls.qwest.net) has quit (Read error: Connection reset by peer)

[10:26:36]

sl1ce (sl1ce!~johnathan@pool-72-74-164-209.bstnma.fios.verizon.net) has joined #mythtv

[10:46:34]

stuarta:

dym: any ideas when you upgraded the HDHR to have the latest firmware?

[11:07:27]

dym:

when?

[11:07:46]

dym:

right away when i deployed it, the hdhr utility ran a firmware upgrade itself

[11:07:58]

dym:

that was before any mythtv coming into play

[11:09:14]

dym:

Please let me know if i can provide you with any more hands-on information. i now have a mythbuntu stable version running, plus a mythbuntu upgrade

[11:11:45]

** stuarta hmms **

[11:15:56]

stuartm:

dym: have you tried running it native, without the vm?

[11:16:14]

dym:

mhhhhhh

[11:16:31]

dym:

i currently have no box that could do that.

[11:16:35]

dym:

or is there an os x version?

[11:20:40]

stuarta:

yes, now where is it....

[11:20:55]

dym:

i have thr frontent version

[11:21:01]

dym:

the*

[11:42:48]

warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has joined #mythtv

[11:43:28]

warpme:

dym: quick Q: are You running guest linux VM under OSX host hypervisor?

[11:54:12]

dym:

warpme: no

[11:54:21]

dym:

Ubuntu Hypervison, with KVM/QEMU

[11:54:38]

dym:

Hypervisor*

[11:54:51]

dym:

well, it doesnt even classify as a hypervisor :D

[11:54:54]

dym:

let's call it host

[11:55:17]

dym:

its plain commanline kvm/qemu – no cloud colorful, clicky thing

[11:55:29]

dym:

s/commanline/commandline

[11:55:41]

dym:

/

[11:55:47]

stuarta:

it's still a hypervisor, i use those all the time ;-)

[12:09:56]

dekarl-work (dekarl-work!51c8c678@gateway/web/freenode/ip.81.200.198.120) has joined #mythtv

[12:10:23]

dekarl-work:

dym, http://www.mythtv.org/wiki/Backend_Mac_OS_X_USA_HDHR_Setup with some DVB specific changes, could do it?

[12:11:05]

dekarl-work:

e.g. don't setup schedules direct, but use EIT instead

[12:11:55]

dym:

geez

[12:11:58]

dym:

okay

[12:12:06]

dym:

i think i have a linux laptop somwhere

[12:12:07]

dym:

:D

[12:12:11]

dym:

ill try that instead

[12:13:57]

dekarl-work:

now that I identified the issue with my IPTV receiption I may be able to look at the mpeg2ts over http patch. then you could test the HDHR as source for the IPTVRecorder (without guide data, though. have to setup xmltv)

[12:29:39]

Roklobsta (Roklobsta!~Roklobsta@ppp118-209-54-69.lns20.mel4.internode.on.net) has quit (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/)

[12:30:16]

warpme:

dym: from root cause analyssis point-of-view I would suggest strategy "start with working then find what breaks". I would start with bare metal with well known OS and latest 0.27fixes. This should work. Then I would start to add virtualization, etc. This sounds like some initial work but when You sun-up frustration and already spent time on alternative appproach – then proposed strategy started to pay-off...

[12:31:53]

warpme:

recording subsytem is real-time and this puts totally new set of requirements for virt. enviroment. I think containers will be MUCH better for Your task here...

[12:36:12]

warpme:

stuartm: I'm wonder did we consider to move HTTP/API stuff to separate exec? Something like mythgateway app doing comm with world unpredictable (in req.param.sense) requests?

[12:42:12]

stuartm:

warpme: no, can't be done, we need direct access to the backend for the services API otherwise it gets far too complicated and slower

[12:43:26]

stuartm:

nothing stopping people putting their own http proxy in front, but there's really nothing to gain by us creating our own proxy app

[12:46:48]

amessina (amessina!~amessina@unaffiliated/amessina) has joined #mythtv

[12:48:44]

warpme:

stuartm: sure with proxy. But it might be only circuit-level proxy. But for minimizing BE down-time causes by wrong/not-yet-implemented param. checking or DOS it will not help I think. Only app-level proxy can help here. I understud main problem is IPC between BE and GW right?

[12:50:12]

stuartm:

warpme: yes, if you have to implement a second API for communication with the backend then it makes the whole thing unmanagably complex and slower

[12:50:40]

stuartm:

currently the WebFrontend, at least in my experience, is blindingly fast, much faster than mythweb ever was – that's a consequence of several factors, one of which is direct access to data already held in-memory by the backend instead of having to query it over the myth protocol

[12:51:54]

amessina (amessina!~amessina@unaffiliated/amessina) has quit (Quit: Konversation terminated!)

[12:51:55]

stuartm:

we've designed the services API to be robust against invalid requests, and it's something which will always remain a high priority

[12:55:05]

warpme:

stuartm: there is for sure speed-stability trade-off. It is mather of individual prorities but seeng 2 BE segfaults only in last 2 days because of HTTP requests to BE (and my average seg. ratio for BE is 1/year) I'm a bit woried. In other words – for critical app – I prefer not to use risky feature than use and risk. But this is for sure mather of tase

[12:55:31]

stuartm:

warpme: interesting, have you filed tickets?

[12:57:13]

stuartm:

I've never seen a crash related to the http server in months of working on it, and even deliberately trying to crash it (short of full random fuzz testing)

[12:57:31]

stuartm:

if there is a problem I'd like to get it fixed ASAP

[12:58:56]

warpme:

No as it was on prod system so it was instantly restarted by systemd. Indeed I have to think-out how to gather core dumps in automated way. I don't know why but my segs with BE in my system log have only 1 line with EIP. No any diag info....

[12:59:57]

stuartm:

without a bt how do you know it was http server related?

[13:00:03]

warpme:

I remember 2nd segfault was when I asked to play recording from WebFrontend

[13:01:20]

stuartm:

warpme: ok, since that request actually goes direct to the frontend and not the backend it's more likely to be a bug which isn't directly related to the http server/API

[13:01:23]

warpme:

purelly by time corelation. I press "Play recording" in browser; browser stalls; 20s later I saw on TV notification "no connection with BE"

[13:01:57]

stuartm:

oh, play recording ... not play recording in frontend ...

[13:02:11]

warpme:

no – it was request to play rec in browser – not in FE

[13:02:21]

stuartm:

ok, that sounds like the HLS code – so again not the services API exactly

[13:03:03]

warpme:

indeed – I can't tell where was root cause :-(

[13:04:51]

warpme:

Eventually I'll try to reproduce this in my testbed (1:1 copy of production BE)

[13:06:15]

dekarl-work:

actually I think it makes more sense to take the recorders out of the master backend and leave the service api in instead

[13:07:06]

warpme:

stuartm: FYI regarding Webfrontend. Using it under Safari/OSX is quite complicated as left-side bar is always visible. Firefox/OSX is OK. Just let You know...

[13:07:30]

dekarl-work:

stuartm, on iOS8 the left-bar stays, too

[13:08:25]

stuartm:

guessing that's the latest version of safari?

[13:08:32]

warpme:

yes

[13:09:58]

stuartm:

ok thanks for letting me know, I'll try to find out why safari behaves differently to chrome, firefox, opera et al but I don't have any Apple gear to test with

[13:10:07]

warpme:

dekarl-work: assuming it will have state-full failover. All this is perfect candidate for msg based IPC (Erlang) with zeromq...

[13:11:00]

stuartm:

fwiw I was going to add a click to hide option, and for small screens I've got something else in mind entirely (currently a work in progress)

[13:11:11]

warpme:

stuartm: how can I help You with this?

[13:11:39]

dekarl-work:

warpme: yes and no, there's no reason to overengineer the solution :)

[13:11:56]

stuartm:

warpme: well you can look for errors in the browser's console (or error logs) which might give a clue why the javascript is failing

[13:12:26]

warpme:

stuartm: sure. Now I'm in work. Will do this at evening.

[13:13:01]

stuartm:

let's not forget the logserver situation, a classic over-engineering example that ultimately caused us so much trouble and wasted man hours that it had to be disabled by default

[13:13:53]

stuartm:

it took something that just worked and broke it while making it much more complicated and harder to maintain

[13:14:29]

stuarta:

i'm still not even sure what problem it was fixing....

[13:15:16]

warpme:

dekarl-work: I'm not sure that msg based IPC is overengnieered. It relieves dev from IPC carefull process/thread synchronization. More – deadlocks/races stops to be nightmare of multithreaded apps. I'm big fan of this approach :-)

[13:15:46]

stuarta:

warpme: what problem are you trying to fix?

[13:18:04]

warpme:

fix is too big word :-) But looking on concept how to organize IPC between say 5 co-working components after BE functional split I'm considering how potentially it can be done with expected stability and limited resources (especially for testing)

[13:18:44]

stuarta:

so if we ever did split the backend into multiple components, something like 0mq based messaging makes sense

[13:18:58]

stuarta:

but, that ain't gunna happen any time soon

[13:19:28]

warpme:

yeah. But why not to drem sometimes :-p

[13:19:40]

warpme:

s/drem/dream/

[13:19:45]

stuarta:

i have plenty, and no time to implement :)

[13:20:54]

warpme:

this is topic curently bothering me little (I mean work-live balance).

[13:29:50]

dekarl-work:

we already have slave backends holding recorders... so I don't see a reason to change the communication "just because we can". But lets cross that bridge once we get there

[13:29:53]

dekarl1 (dekarl1!~dekarl@mythtv/developer/dekarl) has joined #mythtv

[13:30:18]

warpme:

stuarta: regarding 0mq for log server. i think if we want to catch logs in as much as possible corner cases – log server MUST be separate process. If it will be separate proces – resilient IPC must be implemented. From all IPC options, msg based seems to be best for this case. I think our issue with 0mq approach wasn't becaue 0mq itself. It was rather because mythtv project speciffic situation

[13:31:08]

stuarta:

oh i quite like 0mq as a technology. think it's lovely

[13:31:27]

dekarl-work:

step one: does a recording on a slave backend survive a master backend restart? Get that working and improve from there :)

[13:32:27]

dekarl (dekarl!~dekarl@mythtv/developer/dekarl) has quit (Ping timeout: 264 seconds)

[13:32:39]

stuarta:

we can get part the way there with tunerless master backend

[13:35:52]

warpme:

i think 0mq isn't anything new. It is just implementation of well known concept of IPC. For me moving from semaphores/locks to msg is huge change. By this our considerations are purelly teoretical. But if I'm trying to imagine how to design multicomponent app where every component running on diferent host and all have state-full fail-overs then msg based IPC seems to be easier for me. But maybe this is only first-look imperssion.

[13:37:40]

dekarl-work (dekarl-work!51c8c678@gateway/web/freenode/ip.81.200.198.120) has quit (Ping timeout: 246 seconds)

[14:03:41]

stuartm:

there's nothing new about about IPC or zeromq, but ripping apart an existing large and complicated application into two parts and sticking IPC in the middle is a huge task

[14:06:02]

stuartm:

based on previous experience we know that while it might be some benefits, it also introduces new bugs that we'll spend months or years fixing, so ultimately the potential disruption to a recording caused by a rare crash (which needs fixing anyway) becomes a scenario where crashes, hangs and other frustrating bugs become far more common

[14:06:46]

stuartm:

it's one thing to design it into the app from the start, but quite another to retroactively introduce it

[14:07:53]

stuartm:

personally I'd much rather focus that developer time on fixing the existing bugs so crashes just don't happen

[14:08:07]

** stuarta agrees **

[14:12:15]

gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has quit (Ping timeout: 244 seconds)

[14:16:54]

dym:

okay, i've got an update

[14:17:09]

dym:

a technician of my cable company was just here

[14:17:55]

dym:

the company initially installed a signal booster localy and a conduit box underneath to add cable devices

[14:18:14]

stuarta:

interesting

[14:18:45]

stuarta:

that's the sort of crap that causes corrupt signal

[14:19:36]

dym:

yeah

[14:19:42]

dym:

it caused for signal decay

[14:19:45]

dym:

new status: http://drop.openroot.de/3Jr9/IzPcZv6n

[14:20:09]

dym:

the distribution unit stole about 6db

[14:20:39]

stuarta:

lets see how it goes then

[14:20:52]

dym:

well

[14:21:02]

dym:

until now it runs

[14:21:24]

dym:

no digital distortion

[14:21:30]

stuarta:

\o/

[14:21:41]

dym:

(i have also replaced the wireless units with powerline adapters)

[14:21:48]

dym:

but this is non-upgraded

[14:21:59]

dym:

ill try upgraded later, after i removed the mess the technician left in the house :(

[14:24:50]

gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has joined #mythtv

[14:25:12]

dym:

also, funny sidenote: changing channels is now faster – i assume cause of the ability of acquiring a channel lock faster.

[14:29:11]

stuartm:

that's an interesting arrangement, is that inside or outside?

[14:31:58]

stuartm:

never known them to use signal boosters at the property for cable in the UK, think it's usually done at the cabinet if they had to

[14:32:54]

stuartm:

and splitters are usually, though not always, outside in a wall mounted box

[14:56:37]

warpme:

damn: I switched to master 2 days ago. Since that time I had already 5 0B recordings. With my frankenstein 0.27 I had ratio 1 per few weeks/month (1 per 1000..1500rec). Ough – finding root cause will not be easy :-(

[15:01:46]

warpme:

all failed rec had tuner lock and failed with " TVRec[6]: TuningSignalCheck: SignalMonitor timed out"

[15:03:23]

warpme:

candidate to inspect is commit adding " TVRec[5]: TuningSignalCheck: taking more than 15000 ms to get a lock. marking this recording as 'Failing'." Does anybody knows which one does it?

[15:11:03]

warpme:

probably i have to look at https://github.com/MythTV/mythtv/commit/5868f . . . dbc7dfdfc0cc

[15:14:53]

stuarta:

warpme: does it really take 15s to get a lock?

[15:18:20]

warpme:

stuarta: no. Tuner gives lock within 0.1–0.3sec. it is myth issue or...I have bad luck and last 2 days my SAT provider had outages. (BTW: I understand Signalmonitor timeout is not based on tuner lock timeout but rather on lack of detected DVB tables like PMT/etc. Is this correct understanding?)

[15:40:57]

stuartm:

warpme: the signal monitor code has existed for years

[15:58:44]

brfransen (brfransen!~brfransen@24-197-128-95.dhcp.spbg.sc.charter.com) has quit (Quit: Byebye)

[16:01:37]

warpme:

stuartm: right. but https://github.com/MythTV/mythtv/commit/5868f . . . dbc7dfdfc0cc is diference between 0.27 (which had 0B 1 per 3..4weeks) and current master (which has 1 per day). Ofcourse this is only speculation. I'll investigate this. It looks like this commit can be reverted without big problems isn't?

[16:09:21]

brfransen (brfransen!~brfransen@24-197-128-95.dhcp.spbg.sc.charter.com) has joined #mythtv

[16:10:48]

stuarta:

warpme: so turn on --verbose record --loglevel debug and see if any of the debug output from that commit is generated

[16:11:18]

stuarta:

it'll generate significantly more logs, but will give you an idea if that is related at all

[16:11:36]

ElmerFudd:

I have a sound issue when using composite for grabbing from my VCR – when using /dev/oss I get crackling sounds at high volumes and when using my sound card line in the audio slowly gets out of sync

[16:12:35]

stuarta:

warpme: even without it you should see some of "It took longer than %1 ms to get a signal lock."....

[16:12:54]

ElmerFudd:

is it possible to control the input volume from analog? – I can't seem to find any mixer devices for it, but I might lack som oss stuff

[16:16:25]

ElmerFudd:

to answer my own question – mediaclient --volume=<value> ... bah

[16:17:40]

FabriceMG (FabriceMG!~Thunderbi@LCaen-656-1-100-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG)

[16:30:33]

Hydroponx (Hydroponx!~hydr@71-12-104-200.dhcp.mtgm.al.charter.com) has quit (Ping timeout: 256 seconds)

[16:30:51]

Hydr0p0nX (Hydr0p0nX!~hydr@71-12-104-200.dhcp.mtgm.al.charter.com) has joined #mythtv

[16:52:20]

Chutt_ is now known as Chutt

[16:55:56]

warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has quit (Remote host closed the connection)

[17:35:32]

Hydroponx (Hydroponx!~hydr@71-12-104-200.dhcp.mtgm.al.charter.com) has joined #mythtv

[17:37:15]

Hydr0p0nX (Hydr0p0nX!~hydr@71-12-104-200.dhcp.mtgm.al.charter.com) has quit (Ping timeout: 264 seconds)

[17:40:25]

Hydroponx (Hydroponx!~hydr@71-12-104-200.dhcp.mtgm.al.charter.com) has quit (Ping timeout: 265 seconds)

[17:40:54]

dekarl-work (dekarl-work!51c8c678@gateway/web/freenode/ip.81.200.198.120) has joined #mythtv

[17:42:36]

dekarl-work:

Now that the Internet is up again... stuarta, most of our users already have a potentially tunerless MBE :) see https://github.com/MythTV/packaging/blob/mast . . . tuners.patch

[17:47:33]

Hydr0p0nX (Hydr0p0nX!~hydr@71-12-104-200.dhcp.mtgm.al.charter.com) has joined #mythtv

[17:59:03]

Merlin83b (Merlin83b!~Daniel@office.34sp.com) has quit (Quit: Leaving)

[18:33:17]

SteveGoodey (SteveGoodey!~steve@host109-158-208-74.range109-158.btcentralplus.com) has joined #mythtv

[19:04:41]

joki (joki!~joki@p548611F1.dip0.t-ipconnect.de) has quit (Ping timeout: 244 seconds)

[19:10:47]

joki (joki!~joki@p54861A12.dip0.t-ipconnect.de) has joined #mythtv

[19:14:29]

andreaz (andreaz!~andre_000@p5DD14ABE.dip0.t-ipconnect.de) has joined #mythtv

[19:14:58]

Roklobsta (Roklobsta!~Roklobsta@ppp118-209-54-69.lns20.mel4.internode.on.net) has joined #mythtv

[19:20:57]

andreaz (andreaz!~andre_000@p5DD14ABE.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer)

[19:27:49]

dekarl-work (dekarl-work!51c8c678@gateway/web/freenode/ip.81.200.198.120) has quit ()

[20:14:04]

sheedy-away is now known as sheedy

[20:16:31]

sl1ce (sl1ce!~johnathan@pool-72-74-164-209.bstnma.fios.verizon.net) has quit (Remote host closed the connection)

[20:17:38]

sl1ce (sl1ce!~johnathan@pool-72-74-164-209.bstnma.fios.verizon.net) has joined #mythtv

[20:32:12]

tgm4883:

dekarl1: stuarta we've had that for quite a while too

[20:38:39]

Hydr0p0nX (Hydr0p0nX!~hydr@71-12-104-200.dhcp.mtgm.al.charter.com) has quit (Ping timeout: 252 seconds)

[21:19:49]

tgm4883:

sphery_: oh where art thou?

[21:29:51]

len (len!~quassel@75-168-45-25.mpls.qwest.net) has joined #mythtv

[21:30:18]

sheedy is now known as sheedy-away

[21:55:54]

SteveGoodey (SteveGoodey!~steve@host109-158-208-74.range109-158.btcentralplus.com) has quit (Quit: Konversation terminated!)

[22:01:52]

urlgrey (urlgrey!~urlgrey@199-116-73-2.sfo1.office.zencoderdns.net) has joined #mythtv

[22:03:04]

urlgrey:

How can I specify the storage location for recording thumbnails? Currently the thumbnails are being stored in the same directory as the video recording. Is there a special storage group that I need to define?

[22:15:38]

Roklobsta:

i think they are stored with the video files

[22:24:32]

urlgrey:

Roklobsta: is it not possible to change that behavior? The reason I ask is that I've got an SSD for my OS installation with lots of free space, and several slower magnetic drives with recordings, and would like thumbnails to be stored on the SSD for faster MythWeb and frontend loading

[22:25:17]

Roklobsta:

ah yeah i agree it's a good idea but i think once the thumbnails are generated it's probably not going to make a difference.

[22:25:36]

Roklobsta:

you might be better off adding more ram for disk cache to your system

[22:26:26]

urlgrey:

yes, that might work, thanks for answering my question

[22:35:23]

Roklobsta:

the slow part is generating thumbnails.

[22:35:43]

Roklobsta:

i guess the generator has to seek maybe 10mins into the program and grab a screen

[22:35:55]

Roklobsta:

the realy slow part of myth seems to be anything to do with the database

[22:36:00]

stuartm:

both the frontend and mythweb cache the images locally, so once they've been seen there shouldn't be any subsequent slowdown

[22:48:22]

sl1ce (sl1ce!~johnathan@pool-72-74-164-209.bstnma.fios.verizon.net) has quit (Ping timeout: 240 seconds)

[22:48:23]

jpharvey (jpharvey!~jpharvey@host109-148-114-245.range109-148.btcentralplus.com) has quit (Ping timeout: 240 seconds)

[22:57:14]

urlgrey:

stuartm: ah, cool, I wasn't aware that the frontend caches the thumbnails

[22:59:53]

stuartm:

I'm actually not sure how well mythweb caches, but I understand that it is meant to

[23:01:13]

jpharvey (jpharvey!~jpharvey@host109-148-117-201.range109-148.btcentralplus.com) has joined #mythtv

[23:05:35]

Tobbe5178 (Tobbe5178!~asdf@2001:2002:d9d4:ce7e:8512:39a0:3dc6:7966) has quit (Read error: Connection reset by peer)

[23:07:53]

sl1ce (sl1ce!~johnathan@pool-72-74-164-209.bstnma.fios.verizon.net) has joined #mythtv

[23:20:44]

Mrgoose2 (Mrgoose2!~Mrgoose@24.98.94.2) has joined #mythtv

[23:20:46]

Mrgoose2:

sup sup

[23:53:49]

Hydr0p0nX (Hydr0p0nX!~hydr@71-12-104-200.dhcp.mtgm.al.charter.com) has joined #mythtv

[23:54:32]

Hydr0p0nX (Hydr0p0nX!~hydr@71-12-104-200.dhcp.mtgm.al.charter.com) has quit (Client Quit)

[23:54:52]

Hydr0p0nX (Hydr0p0nX!~hydr@71-12-104-200.dhcp.mtgm.al.charter.com) has joined #mythtv

MythLogBot@irc.freenode.net :: #mythtv

Current users (75):