| Friday, June 28th, 2013, 03:47 UTC | ||
| [03:47:32] | xris: | woot! |
| [03:47:32] | xris: | trout Beirdo |
| [03:47:32] | xris: | ah, he turned off that plugin. |
| [03:49:01] | xris: | cool, I even have commit access so I can fix it in the repo |
| [03:51:45] | ** xris goes back to dreaming about 3d printers ** | |
| [04:15:23] | joki (joki!~joki@p54864FF8.dip0.t-ipconnect.de) has quit (Ping timeout: 240 seconds) | |
| [04:20:08] | joki (joki!~joki@p5486522A.dip0.t-ipconnect.de) has joined #mythtv | |
| [05:23:41] | jya: | with very recent version of myth (not sure when it started), i now see in the backend log: QObject::startTimer: timers cannot be started from another thread |
| [05:23:49] | jya: | QObject::killTimer: timers cannot be stopped from another thread |
| [05:23:56] | jya: | that's in liveTV |
| [05:28:19] | jya: | looks like it's IPTVChannel::KillTimer()... |
| [05:28:44] | jya: | has something changed in the thread structure with the IPTVChannel? |
| [05:28:56] | jya: | was certainly all running within the same thread before |
| [05:29:56] | jya: | jpabq: it's probably your moving of signal monitor into TVRec... |
| [05:31:10] | jya: | in any case; this broke IPTV playback |
| [05:31:19] | jya: | @%@%# |
| [05:38:30] | jya: | jpabq: I think your change in moving the signal monitor introduce a major issue. It now means that entire recorders block must now be thread-safe with the signal monitor and recorder now accessing the same data from two different threads… you've opened a massive can of worms…. so close to feature freeze it's a very rsiky gamble |
| [05:41:02] | jya: | danielk221: had made the whole scene nice and elegant with his tvrec branch, I'm afraid that work has been greatly compromised… Was there any particular reason for the need to move the signal monitor? |
| [05:55:27] | SteveGoodey (SteveGoodey!~steve@host86-145-235-230.range86-145.btcentralplus.com) has joined #mythtv | |
| [06:13:54] | SteveGoodey (SteveGoodey!~steve@host86-145-235-230.range86-145.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [06:28:00] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [07:05:55] | stichnot (stichnot!~stichnot@adsl-68-125-54-123.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [07:05:56] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [07:05:56] | stichnot (stichnot!~stichnot@adsl-68-125-54-123.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [07:09:38] | peper03: | MythLogBot is back but the web page is gone :( |
| [07:11:56] | peper03: | stichnot: GetTotalSeconds is not called from anywhere. MythPlayer::calcSliderPos does two runs to get the times with and without the cutlist. GetTotalSeconds always ignores the cutlist. |
| [07:23:26] | stichnot (stichnot!~stichnot@216.239.45.130) has joined #mythtv | |
| [07:23:27] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [07:23:27] | stichnot (stichnot!~stichnot@216.239.45.130) has quit (Changing host) | |
| [07:37:45] | toeb: | jya, stuartm, about your discussion of notifications with confirmation: Instead of the standard options of ok/cancel it would be nice if one could give it a bunch of options and receive the selection. I'm thinking of a something like an asterisk plugin with call notification which lets the user decide what to do (e.g. Ignore Call, Send to Mailbox, Play announcement 1,2,3.. or what ever..). In the case the someone gets ar |
| [07:39:10] | peper03: | stichnot: (don't think you saw this) GetTotalSeconds is not called from anywhere. MythPlayer::calcSliderPos does two runs to get the times with and without the cutlist. GetTotalSeconds always ignores the cutlist. |
| [07:43:14] | stuarta: | stuartm: cheers for that buildbot stuf |
| [07:43:47] | jya: | well, something is very screwed up with live tv now… the IPTV recorder is broken for once… liveTV just doesn't start anymore, I get a lock signal showing, with nothing else happening after… When I press rewind, *sometimes* livetv will start, but then the progress bar doesn't refelct at all what's actually happening, it keeps showing as if I was live, when I could have rewinded a minute |
| [07:58:37] | peper03: | stuarta: Does something else need to be started for the web interface to Beirdobot? I'm getting a 404 at the moment '/opt/beirdobot/share/beirdobot/web/beirdobot.php/channel/4/history was not found on this server.' |
| [08:02:44] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Ping timeout: 256 seconds) | |
| [08:08:32] | stuarta: | peper03: the bot won't start |
| [08:08:40] | stuarta: | i'll email Beirdo |
| [08:11:53] | stuarta: | peper03: ah, hmm, the bot is fixed, just the web interface is snafu |
| [08:12:05] | peper03: | Yeah, I was just going ask :) |
| [08:13:18] | peper03: | Ask if it's not just the web interface, I mean. |
| [08:18:43] | stuarta: | i'll look at it in a bit |
| [08:18:58] | peper03: | np |
| [08:29:02] | ** stuarta has some real work to do first ** | |
| [08:35:09] | stuartm: | stuarta: in case it wasn't clear, the purpose of build.sh is just to get coverity to combine the results for core + plugins, it just looks at the arguments passed to gcc to see which files/defines/libs are actually used |
| [08:38:45] | stuartm: | for that reason it should give different results for other platforms, but coverity only let's us submit one build for now – still, could be interesting to submit builds for windows and osx at least once so that we can squash any major bugs in the platform specific code |
| [08:41:10] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [08:43:20] | Nothing4You (Nothing4You!N4Y@Nothing4You.w.tf-w.tf) has quit (K-Lined) | |
| [08:47:37] | Nothing4You (Nothing4You!N4Y@Nothing4You.w.tf-w.tf) has joined #mythtv | |
| [08:54:50] | jya: | stuartm: did you see the last coverity email on how they;ve changed their submit process and that it could now be fully automated? |
| [08:55:22] | Nothing4You is now known as NOTHING4YOU | |
| [08:56:37] | stuartm: | jya: yeah I saw it, strange thing is that it hasn't changed, at least not recently, they've had the 'automated' submission stuff for a while now |
| [08:57:10] | stuartm: | I think maybe that was mentioned for the benefit of people who haven't looked at their site for a few months |
| [08:58:14] | stuartm: | the automatic submission is just a curl command line, nothing too fancy |
| [09:00:19] | jya: | sigh… still can't figure out what broke IPTV live TV… I'm at my 2nd git bisect now, and I found a different culprit |
| [09:35:37] | exoon (exoon!~exoon@p4FD3982B.dip0.t-ipconnect.de) has joined #mythtv | |
| [09:36:16] | jya: | stuartm: according to git bisect, your change in doxygen broke liveTV for IPTV :) |
| [09:36:25] | jya: | well, that's my 3rd go at it |
| [09:36:28] | stuartm: | cool :) |
| [09:36:30] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Ping timeout: 268 seconds) | |
| [09:40:31] | jya: | I'm a tad baffled; this was wroking beautifully when I finished the hls recorder |
| [09:41:09] | jya: | ah and now it works with master... |
| [09:41:35] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [10:53:36] | jya: | danielk221: the issue of different thread being used may be deeper than I thought; but for some reason is only revealed now. The various channels are created by TVRec right when mythbackend starts; and as such are created in the main thread. Then TVRec moves into its own thread and start using the object it created earlier. So all the objects have now been created in a thread different to the thread using it… Not much of a problem |
| [10:53:37] | jya: | per say ; except that Qt doesn't like it; refuses to create the required timer used by IPTV and the HLS encoder ; and now everything fail… Why it worked last week, but not know; is a mystery to me… I guess I could put the appropriate moveToThread() somewhere ; but that will work for the base channel class, but none of the object it created itself … any ideas ? |
| [11:08:12] | jsc_ (jsc_!de98b132@gateway/web/freenode/ip.222.152.177.50) has joined #mythtv | |
| [11:08:27] | jsc_ (jsc_!de98b132@gateway/web/freenode/ip.222.152.177.50) has quit (Client Quit) | |
| [11:23:17] | toeb (toeb!~toeb@HSI-KBW-109-193-196-029.hsi7.kabel-badenwuerttemberg.de) has quit (Read error: Connection reset by peer) | |
| [11:37:44] | jasoncullen (jasoncullen!~androirc@222-152-177-50.jetstream.xtra.co.nz) has joined #mythtv | |
| [11:45:13] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Quit: Ex-Chat) | |
| [11:48:17] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 248 seconds) | |
| [11:49:36] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [11:50:04] | exoon (exoon!~exoon@p4FD3982B.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds) | |
| [12:01:28] | sraue_ (sraue_!~stephan@91-114-176-148.adsl.highway.telekom.at) has joined #mythtv | |
| [12:03:32] | toeb (toeb!~toeb@HSI-KBW-109-193-196-029.hsi7.kabel-badenwuerttemberg.de) has joined #mythtv | |
| [12:03:33] | exoon (exoon!~exoon@p4FC3FF72.dip0.t-ipconnect.de) has joined #mythtv | |
| [12:12:43] | jya: | danielk221: looking at TVRec; many of the objects are created in the TVRec::run() event loop (running on a secondary thread); yet, the deletion of them is done in the TVRec destructor; well after the TVRec thread has been deleted… I guess, it doesn't really matter much as mythbackend is never supposed to exit… but that could certainly explain why (at least for me on mythbuntu), calling services mythtv-backend usually hangs |
| [12:24:22] | Cougar (Cougar!~cougar@2a03:5880:104:10:ed2c:d960:4cca:c04e) has quit (Ping timeout: 246 seconds) | |
| [12:26:16] | Cougar (Cougar!~cougar@2a03:5880:104:10:711c:7cff:d4e0:99ed) has joined #mythtv | |
| [12:29:48] | dekarl1 (dekarl1!~dekarl@p4FE85A1C.dip0.t-ipconnect.de) has joined #mythtv | |
| [12:32:19] | dekarl (dekarl!~dekarl@p4FE85CB6.dip0.t-ipconnect.de) has quit (Ping timeout: 264 seconds) | |
| [12:57:59] | stichnot: | peper03: For now, in calcSliderPos(), I think you could set fixed_playbacklen=true and playbackLen=GetTotalSeconds() if playing a DVD (though I don't know the best way of testing whether it's a DVD) |
| [12:58:52] | neufeld: | stichnot: as the logbot has been inattentive, you might not have seen the patch message I sent you last night: `` OK, first proposed mythccextractor patch. Handle SIGINT and SIGTERM gracefully, writing out buffers. https://github.com/ChristopherNeufeld/mythtv/ . . . 443fdccc478b '' strace shows more data being written to disc after the SIGINT arrives. |
| [13:00:17] | stichnot: | neufeld: thanks, looking now |
| [13:01:00] | neufeld: | stichnot: if you're surprised at some of the extra code, it's because signal handlers in the MythTV framework won't be invoked without an event loop, and mythccextractor didn't have an event loop, so I had to re-do main() to use one. |
| [13:05:00] | neufeld: | I'm sure I didn't hook it into the build system in a usual way. Nobody else puts a .moc filename in a .pro. |
| [13:07:31] | nyloc (nyloc!~quassel@p4FE4C1AE.dip0.t-ipconnect.de) has quit (Read error: Operation timed out) | |
| [13:07:56] | stichnot: | No big surprise there. As for signals, as far as I know, signal handling (as in SIGINT) has been wonky for a long time. My solution is to send the signal twice. BTW, I would also try adding a customEvent() method and respond to a REC_FINISHED event by quitting. |
| [13:08:25] | jya: | How applicable is "Don't use Qt signals and slots in backend code There are a number of gotchas with signals and slots and we're decided to use them only in UI code as a result of dealing with all the hard to debug crashes that have resulted." |
| [13:08:48] | stichnot: | neufeld: could also do the same for master backend started/shutdown events to be safe |
| [13:08:58] | jya: | I don't see how I could resolve the current issue of simultaneous QThread running, without the use of signal/slots :( |
| [13:09:15] | neufeld: | stichnot: those events are IPC? |
| [13:09:37] | stichnot: | yes |
| [13:09:44] | nyloc (nyloc!~quassel@p4FE4C1AE.dip0.t-ipconnect.de) has joined #mythtv | |
| [13:10:21] | stichnot: | e.g. if I run "mythfrontend -v network" I get to see all those system events from the backend in the logs |
| [13:11:28] | stichnot: | and yeah, that .moc stuff doesn't look right |
| [13:11:31] | neufeld: | stichnot: as for signals (interrupts, not Qt things), the usual case is like this: The binary puts in handlers for all the usual ones. When an interrupt arrives, like SIGINT, it raises an event that asks the user-supplied signal handler to be invoked in a thread, not interrupt context. However, SIGINT and SIGTERM are not reset, they're effectively single-shot handlers. So the next time one of those interrupts |
| [13:11:31] | neufeld: | arrives, it hits default handling, which is to exit the program immediately. Sending the signal twice isn't actually wonkiness, it appears to be designed and intended behaviour. |
| [13:12:40] | stichnot: | I mean it's wonky in that e.g. you try to ctrl-c the frontend and it takes many seconds to die, if it dies at all |
| [13:14:09] | neufeld: | stichnot: I've certainly seen that (signal insensitivity) in the backend. |
| [13:17:24] | neufeld: | stichnot: as for REC_FINISHED, when I've got two recordings going, and one completes, how does the appropriate mythccextractor know that it's the one that's supposed to exit while the other one keeps going? Similarly, mythccextractor does not have to be run synchronously with an in-progress recording, it doesn't need a backend to exist in order to run, so I don't think it should care about the state of the master |
| [13:17:25] | neufeld: | backend. |
| [13:17:28] | stichnot: | anyway, I would deal with that in the shell script by sending two kill signals to be safe |
| [13:18:27] | neufeld: | stichnot: sure, but with a few seconds in between... |
| [13:24:39] | stichnot: | neufeld: For one thing, mythccextractor should be extended to take --chanid and --starttime arguments. That would allow it access to the ProgramInfo object, which includes the end time, so you wouldn't risk having mythccextractor running forever. This also allows it to respond to only the appropriate REC_FINISHED event. |
| [13:26:21] | stichnot: | Also, mythccextractor needs better control over the output filename(s). |
| [13:28:45] | stichnot: | Responding to REC_START_FINISHED would be useful if an in-progress recording ends earlier than expected, e.g. live TV exit/channel change, or an in-progress recording is cancelled |
| [13:30:08] | neufeld: | Yes, I agree. Output filename is on my list of things that need to be changed. Those are good ideas on the event side of things, I'll put effort into those next. Thank you. |
| [13:31:51] | stichnot: | neufeld: thanks! (sometimes I wonder if you and I are the only ones who will use this...) |
| [13:33:57] | neufeld: | I know that feeling! Still, open source, itch to be scratched, contributing. I've been involved in CC on MythTV and v4l for years now, because my wife's first language isn't English and she sometimes finds captions helpful. |
| [13:36:49] | stichnot: | Same here. I wouldn't have considered using MythTV in the first case if it didn't have closed caption support. After watching with them because of my wife, I'm now addicted. |
| [13:40:47] | peper03: | stichnot: I'll have a look in a bit. I'm sure there must be a clean way of overriding something in MythDVDPlayer. It would be nice to be able to avoid having to add something like 'if(isDVD)' to MythPlayer if we have a DVD specific derived class.. |
| [13:43:26] | stichnot: | peper03: I think in some refactoring, I removed the call to GetTotalSeconds(), but didn't removed the methods themselves for if/when this very issue came up. :) |
| [13:45:01] | stichnot: | Another possibility is to change the signature to int64_t GetTotalSeconds(bool honorCutList), call it in calcSliderPos(), and ignore the argument in MythDVDPlayer |
| [13:46:31] | peper03: | That's exactly what I was just thinking :) GetSecondsPlayed already has the 'honorCutList' parameter, so adding it to GetTotalSeconds gives a nice symmetry :) |
| [13:50:43] | peper03: | I was going to say, I'd call TranslatePositionToMs(total_frames), as is currently done in calcSliderPos, but calcSliderPos uses a local variable, not the member. It gets set to -1 if IsWatchingInprogress() returns true. |
| [13:52:17] | peper03: | Maybe query IsWatchingInProgress again in calcSliderPos at the point where we now call Translate.... and only call Translate in that case, otherwise GetTotalSeconds? |
| [13:52:46] | peper03: | Seems there's enough potential to break something here whilst fixing something else. |
| [14:00:21] | stichnot: | peper03: not sure I'm quite following, but if you get it working properly for DVD still frames, I'll review it for the other cases. |
| [14:01:55] | peper03: | stichnot: Yeah, sorry, hard sometimes to explain moving multiple calls round without being able to point at something. As soon as I've got something working, I'll give you a shout. |
| [14:02:20] | stichnot: | np. I get the basic idea. |
| [14:02:47] | stichnot: | and I see the issue with total_frames, totalFrames, and IsWatchingInProgress() |
| [14:04:23] | peper03: | I think it might be possible to fix it by moving that stuff to GetTotalSeconds with a little help from GetCurrentFrameCount. Just have to see where totalDuration comes into play. |
| [14:20:08] | jpabq_: | jya: I did not move the signal monitor into TVRec. I just moved the LOCK timeout handling there. The signal monitor was starting a timer, and if enough time had passed without a lock, it would abort the signal monitor — that was removed. Instead TVRec now make note of the date/time and uses it to determine if too much time has gone by for a LOCK from the signal monitor. |
| [14:20:26] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG) | |
| [14:20:55] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [14:21:39] | jya: | jpabq_: ok.. something else is broken then :)… I'm getting around it by tweaking the IPTV recorder… but that requires the channel to be created in the main thread, while being used in another |
| [14:22:38] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Disconnected by services) | |
| [14:22:42] | jpabq_ is now known as jpabq | |
| [14:22:56] | jpabq (jpabq!~quassel@67-0-30-72.albq.qwest.net) has quit (Changing host) | |
| [14:22:56] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv | |
| [14:23:39] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Client Quit) | |
| [14:23:54] | jpabq: | jya: I set a timeout of 1 minute for a lock from IPTV — is that too short? |
| [14:23:58] | jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has joined #mythtv | |
| [14:24:23] | jya: | well, if I can't fix the problem I'm encountering now, 1 minute is indeed going to be too short |
| [14:24:29] | jya: | thought it seems to be 2 minutes |
| [14:24:36] | jya: | why 1 minute to short? |
| [14:24:54] | jya: | 1 minute actually leave less than 30s for the HLS to get a lock |
| [14:25:05] | jpabq: | Right — for recording purposes, it doubles the value the user sets for channel_timeout. |
| [14:25:34] | jya: | because the way the whole recording chain work. The signal monitor starts, create a stream handler, once it has a lock, it kill the stream handler (set it to 0) then call the recorder, which call another stream handler |
| [14:26:03] | jpabq: | jya: with the new code, the user can set the timeout to whatever they want, in the capturecard config (in mythtv-setup). I set the /default/ to be one minute, which gets doubled for actual recordings. |
| [14:26:04] | jya: | as it's the stream handler that create the HLS conection, that means: connect, download, check, disconnect, connect, download start. |
| [14:26:11] | jya: | that doesn't give enough time |
| [14:26:29] | jya: | you could always set the lock timeout in mythtv-setup |
| [14:26:45] | jya: | I had set it to 1 minute (60000) as it's the highest value I could set there |
| [14:26:52] | jpabq: | If we need to adjust the default to be larger for IPTV, that is easy to do. |
| [14:26:56] | jya: | would be nice to have it higher really |
| [14:27:19] | jya: | is that any different to the lock timeout you set in mythtv-setup? |
| [14:28:04] | jpabq: | I had not noticed that it had a 60000 cap. I will look at that... |
| [14:28:08] | peper03: | stichnot: http://pastebin.com/jacSVCR7 Quick check with LiveTV, recording in progress, recorded, video and DVD (with still) didn't seem to show anything bad up. |
| [14:28:22] | jya: | but which new timeout value are you talking about? |
| [14:30:02] | jpabq: | It uses channel_timeout. |
| [14:31:32] | jya: | sorry, I just don't follow.. |
| [14:32:09] | jya: | you seem to talk about a new timeout value ; is this any different to the timeout value set in myhttv_setup for the tuning timeout? |
| [14:32:24] | jpabq: | Looks like it called "tuning timeout" on |
| [14:33:14] | jpabq: | It is letting me set it greater than 60000.... |
| [14:33:26] | jya: | so why the need to update the database, an updating all values… I must have missed something obvious, because nothing makes sense to me regarding that |
| [14:33:43] | jpabq: | jya: No, it is not a new value. It is just that that value was not used during the recording process before. |
| [14:34:07] | jya: | I mean, you've updated the database schema, and checked all timeout value. |
| [14:34:22] | jpabq: | The DB update was to ensure that the value in the DB was AT LEAST the default. |
| [14:34:26] | jya: | jpabq: it wasn't used? you're sure? |
| [14:34:38] | jya: | how funny.. |
| [14:34:53] | jpabq: | It was not used for RECORDING. It was used for channel scanning and such. |
| [14:35:03] | jya: | I see |
| [14:36:31] | jpabq: | I agree that it is strange that it was not being used for recordings. |
| [14:40:07] | jpabq: | jya: To be clear, that timeout is only for the signal MONITOR, not the signal HANDLER. Once the recording processes gets past the MONITOR, and the recording actually starts, there is no timeout. The MONITOR is there to make sure we can get a lock, and any program stream tables we want to see, BEFORE trying to actually record. |
| [14:40:51] | jpabq: | The monitor is also used to gather EIT and such. |
| [14:40:52] | jya: | i see… so if it started, had a proper lock; then starts recording ; it wouldn't detect any timeout there. |
| [14:41:02] | jpabq: | Correct. |
| [14:43:18] | jpabq: | jya: I did try HLS a couple of weeks ago. I noticed that when a HLS feed went off the air, that the hls recorder didn't seem to noticed and actually ended up in a bit of a wedged state. I will look into that sometime. |
| [14:44:07] | jya: | jpabq: the HLS ringbuffer; will attempt to download a segment about 3 times, per stream available |
| [14:44:37] | jya: | so if a HLS stream, has 3 substreams, it will try up to 9 times.. can take a while for MDM to timeout |
| [14:45:05] | jya: | but yes, as it is today, the HLS ringbuffer once started is never killed |
| [14:45:13] | jya: | that's what Im currently looking into |
| [14:45:22] | jpabq: | In this case it was happily recording for a little over an hour, and then the HLS stream stopped, but Myth kept trying to "record" it. |
| [14:45:42] | jpabq: | At least that is what seemed to be happening. I will look into it. |
| [14:45:58] | jya: | problem is that I'm using a QObject timer; and as it's started in the main thread, and then moved into the event thread; timer stop working |
| [14:46:23] | jya: | so the timer event never fires, and it just never kills it |
| [14:47:53] | jya: | TVRec is a QRunnable, so when it runs its thread, there's no event loop going on. so I can't easily move the creation of the channel into the event thread |
| [14:49:53] | jpabq: | What are you using the QObject timer to trigger? |
| [14:50:13] | bobweaver: | *** WARNING *** The program 'MythTV-QML' uses the Apple Bonjour compatibility layer of Avahi. |
| [14:50:13] | bobweaver: | *** WARNING *** Please fix your application to use the native API of Avahi! :) :) :) :) :) no more guessing ! |
| [14:51:10] | jya: | jpabq: prevent the HLS stream to be closed between the time the signal monitor finishes and the time the recorder starts. |
| [14:51:29] | jpabq: | Ah |
| [14:51:34] | jya: | otherwise, the frontend times out too early, and liveTV never starts |
| [14:51:47] | jya: | so when I exit the signal monitor, I create a 5s timer |
| [14:52:01] | jya: | if the timer goes off, then the stream is deleted; |
| [14:52:13] | jpabq: | Yeah... |
| [14:52:16] | jya: | if we try to use the stream handler before that timer fires, then we keep it |
| [14:52:30] | jya: | that was the key thing I put to get live TV to work with HLS |
| [14:52:37] | jya: | but somehow this is now broken |
| [14:53:17] | jya: | the reason being , the channel is created in thread 1, the signal monitor is in thread 14, and the recorder is in thread 42 |
| [14:53:23] | jya: | (at least on my mac) |
| [14:53:44] | jya: | so the creation of the timer fails . |
| [14:53:47] | jya: | it used to work |
| [14:53:59] | jya: | not sure what I changed on my side for the timer to suddenly fail |
| [14:55:47] | jya: | what I've done right now (and it seems to be working), is keep the creation of channel in the main thread, and set a continuous 5s timer. that timer will fire every 5s, and I check a keep_alive value… I have a boolean that indicate the stream buffer is to be deleted. when the timer fires, sees that keep alive is false, and the marker to delete the stream is set: it will be deleted… game over |
| [14:56:05] | jya: | i just don't create the timer only when I need it. |
| [15:00:40] | jpabq: | jya: Instead of delaying the signal monitor deleting via a timer, could we re-order the code, such that the recorder is started before deleting the signal monitor? I am not sure of all the ramifications, but that would also solve the problem... |
| [15:01:02] | jya: | won't work. |
| [15:01:16] | jya: | well, not easily |
| [15:01:32] | jya: | if you look at how the signal monitors are working for all recorders |
| [15:02:10] | jya: | once they are done with finding a signal |
| [15:02:25] | jya: | they call Channel::SetStreamData(0) |
| [15:02:51] | jya: | that, for all channels (but IPTV) means: close the stream handler |
| [15:02:53] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 240 seconds) | |
| [15:03:15] | jya: | I guess for DVB and the like, it doesn't really matter, because closing the card and reopening it is very fast. |
| [15:03:41] | jya: | but for IPTV or HLS , starting a new connection may take a while… IPTV was closing it too before |
| [15:03:56] | _nyloc_ (_nyloc_!~quassel@p4FE4DA85.dip0.t-ipconnect.de) has joined #mythtv | |
| [15:05:54] | nyloc (nyloc!~quassel@p4FE4C1AE.dip0.t-ipconnect.de) has quit (Ping timeout: 252 seconds) | |
| [15:06:03] | jpabq: | Ah, thanks for pointing that that is the mechanism. I was just looking at the code and didn't see where the monitor was being deleted before the recorder was started. |
| [15:06:38] | jya: | took me a while to figure out how to get around this in the HLS encoder, so that damn frontend wouldn't time out too quickly |
| [15:07:53] | jya: | personally, instead of calling SetStreamData(0), I would have instead added a method to be simply removed from the listener |
| [15:08:19] | jya: | only should the signal monitor fail to get a signal, would you call SetStreamData(0) |
| [15:09:33] | jya: | then it's up to the recorder, when done to call SetStreamData(0); so you preserve the stream handler between the two. this would remove the need to close/open the card twice each time you start a recording |
| [15:13:56] | jpabq: | Yeah. jya I will look through that code and see what can be done there, a bit later on today. |
| [15:15:42] | jya: | at least it's much easier than in earlier version… since danielk221 reworked the recorders… now the signal monitor exits in a much more simplistic fashion… before that, you never knew if it exited successfully, being pause etc… so it was impossible to tell when to close the stream handler |
| [15:16:29] | jya: | i'm going to push my change to tv_rec and iptvchannel. I only delete the object in the thread they got created |
| [15:17:30] | jya: | it doesn't matter much really now, as none of those objects are Qt ones, but it's more elegant |
| [15:19:10] | jya: | ah, yet another crash in LiveTVChain::finished recording... |
| [15:19:16] | jya: | happens a fair amount here |
| [15:34:34] | jya: | jpabq: actually, calling SetStreamData(0) is unique to the IPTV recorder… But looking at the logic of the other signal monitor; they all do somehting similar... |
| [15:36:10] | jya: | that gives me an idea for the IPTV recorder; I;'ll look into it tomorrow… at least now I can watch live TV (I only have HLS recorder on that machine) |
| [15:38:38] | jya: | jpabq: you're experienced with theme.. did you see my email on the theme mailing list? any ideas? |
| [15:41:56] | jpabq: | jya: I saw your stuff about the theme. If I understand what you are trying to achieve, it will require some coding changes to mythui to do correctly. Very unlikely I will have time to tinker with that before the freeze. |
| [15:42:34] | jya: | I was afraid to be the case… I think I can hack something quickly that will give the behaviour I want.. except that it won't be themable |
| [15:43:01] | SteveGoodey (SteveGoodey!~steve@host86-145-235-230.range86-145.btcentralplus.com) has joined #mythtv | |
| [15:45:04] | jpabq: | jya: Go ahead and hack.... Looking at your hack might help me get a clear understanding of what you want, and then I could evaluate what it will take easier. |
| [15:45:46] | jya: | i had hoped to do that today…. instead i got stuck into this TVRec stuff |
| [15:46:35] | jpabq: | Isn't that the way it always happens ;-) |
| [15:58:01] | jya: | the frontend is definitely not working anywhere as well as it used to for live TV… often get one image and it stuck there, have to rewind... |
| [15:59:24] | jya: | doing my bisect ; one place where it was working well consistently was 77645970804c2279c9179f86e3490cf6106426f8 |
| [16:06:51] | jpabq: | jya: I assume you looked at 1c8e30b140dd7b314fc1d6134a486893b29d6725 |
| [16:07:45] | jya: | no I haven't… but the channels for IPTV are downloaded during the setting of the capture card in mythtv-setup |
| [16:07:55] | jya: | so even if it did break something; I wouldn't know |
| [16:08:13] | jya: | as I haven't played with the capture card definition |
| [16:09:44] | rsiebert (rsiebert!~quassel@g225049046.adsl.alicedsl.de) has joined #mythtv | |
| [16:10:10] | ** jya off to bed. ** | |
| [16:10:35] | jpabq: | sleep well |
| [16:13:00] | rsiebert_ (rsiebert_!~quassel@g224249242.adsl.alicedsl.de) has quit (Ping timeout: 252 seconds) | |
| [16:14:27] | xris (xris!~xris@mythtv/developer/xris) has quit (Quit: Terminated with extreme prejudice - dircproxy 1.2.0) | |
| [16:16:11] | stichnot (stichnot!~stichnot@216.239.45.85) has joined #mythtv | |
| [16:16:12] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [16:16:12] | stichnot (stichnot!~stichnot@216.239.45.85) has quit (Changing host) | |
| [16:29:43] | sraue_ is now known as sraue | |
| [16:29:46] | sraue (sraue!~stephan@91-114-176-148.adsl.highway.telekom.at) has quit (Changing host) | |
| [16:29:46] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
| [17:03:24] | xris (xris!~xris@xris.forevermore.net) has joined #mythtv | |
| [17:13:29] | bill6502 (bill6502!~bill@205.178.26.43) has joined #mythtv | |
| [17:56:12] | exoon (exoon!~exoon@p4FC3FF72.dip0.t-ipconnect.de) has quit (Remote host closed the connection) | |
| [17:58:21] | SteveGoodey (SteveGoodey!~steve@host86-145-235-230.range86-145.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [18:07:36] | NightMonkey (NightMonkey!~NightrMon@64.124.185.45) has joined #mythtv | |
| [18:07:36] | NightMonkey (NightMonkey!~NightrMon@64.124.185.45) has quit (Changing host) | |
| [18:07:36] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [18:08:16] | bobweaver: | What is the service name for bonjour service type example: bonjourBrowser->browseForServiceType(QLatin1String("WHAT_GOES_HERE" )); thanks :) |
| [18:08:20] | knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Quit: Leaving) | |
| [18:17:26] | nyloc (nyloc!~quassel@p4FE4CA3A.dip0.t-ipconnect.de) has joined #mythtv | |
| [18:20:52] | bobweaver: | might be _mythbackend-master._tcp |
| [18:21:16] | _nyloc_ (_nyloc_!~quassel@p4FE4DA85.dip0.t-ipconnect.de) has quit (Ping timeout: 256 seconds) | |
| [18:22:03] | bobweaver: | \0/ \o/ YES !!! |
| [18:22:29] | bobweaver: | looks like there is also a slave to |
| [18:22:41] | bobweaver: | This is Awesome I Love QT and MythTV |
| [18:23:40] | bobweaver: | http://imagebin.org/262776 |
| [18:40:39] | peper03: | stichnot: That patch I pointed you to seems to work but I just realised that indefinite stills probably need some special handling. The timeout of an indefinite still is 255, so that the moment the OSD shows 'xx:xx of 4:15' (i.e. 255 seconds). Any thoughts on how to handle that? |
| [18:41:41] | peper03: | The 'xx:xx of yy:yy' string could be changed to 'still frame' or something like that but what to put in the 'totalseconds' values etc.? |
| [18:43:57] | _nyloc_ (_nyloc_!~quassel@pC19F5157.dip0.t-ipconnect.de) has joined #mythtv | |
| [18:46:19] | stichnot: | indefinite means infinite? |
| [18:47:04] | peper03: | Yes |
| [18:47:29] | nyloc (nyloc!~quassel@p4FE4CA3A.dip0.t-ipconnect.de) has quit (Ping timeout: 248 seconds) | |
| [18:47:29] | peper03: | Basically until a trigger comes to move it on (usually hitting OK) |
| [18:49:39] | peper03: | They can come any time but most often used in menus |
| [18:50:25] | stichnot: | I think you need to make GetSecondsPlayed and GetTotalSeconds return 0 in this case. Presenting text indicating still frame will require theme changes. |
| [18:54:29] | peper03: | Ok. Changing the return values of GetSecondsPlayed and GetTotalSeconds is easy. I assumed the theme (currently testing with MythCenter-wide) displayed the 'description' text, but I suppose it makes more sense that it's plugging the numerical values in to make the text translatable. |
| [18:56:57] | peper03: | It won't show '00:00 of 00:00' though as totalSeconds gets run through "max(playbackLen, 1)", so it would show '00:00 of 00:01'. I could add code to handle that scenario. It's not a huge thing, but it is visible for the user. |
| [18:58:17] | peper03: | Maybe define -1 as a return value for GetTotalSeconds and GetSecondsPlayed if there's no timeout? |
| [19:30:30] | stichnot: | peper03: d'oh! I missed the "description" field in calcSliderPos() so I assumed it was a theme string. |
| [19:31:43] | stichnot: | I think it would be most pleasing to see "description" as tr("Still Frame"), and the other time strings as 00:00. |
| [19:33:40] | peper03: | stichnot: Yes, I agree. I'll see how cleanly I can get that in (hate dirtying clean program flow with a load of 'if's that feel like they've been 'crow-bar'ed in!) |
| [19:33:53] | stichnot: | sounds good, thanks! |
| [19:35:57] | nyloc (nyloc!~quassel@p4FE4CED9.dip0.t-ipconnect.de) has joined #mythtv | |
| [19:40:01] | _nyloc_ (_nyloc_!~quassel@pC19F5157.dip0.t-ipconnect.de) has quit (Ping timeout: 256 seconds) | |
| [19:56:16] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
| [20:00:41] | SteveGoodey (SteveGoodey!~steve@host86-145-235-230.range86-145.btcentralplus.com) has joined #mythtv | |
| [20:03:07] | _nyloc_ (_nyloc_!~quassel@p4FE4C6DA.dip0.t-ipconnect.de) has joined #mythtv | |
| [20:03:34] | nyloc (nyloc!~quassel@p4FE4CED9.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds) | |
| [20:13:13] | peper03: | stichnot: http://pastebin.com/sfihfVkJ |
| [20:24:44] | nyloc (nyloc!~quassel@p4FE4C999.dip0.t-ipconnect.de) has joined #mythtv | |
| [20:27:55] | Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
| [20:28:46] | _nyloc_ (_nyloc_!~quassel@p4FE4C6DA.dip0.t-ipconnect.de) has quit (Ping timeout: 256 seconds) | |
| [20:48:44] | _nyloc_ (_nyloc_!~quassel@p4FE4C0D4.dip0.t-ipconnect.de) has joined #mythtv | |
| [20:52:33] | nyloc (nyloc!~quassel@p4FE4C999.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds) | |
| [20:52:47] | Captain_Murdoch: | wagnerrp, I thought the correct answer on the ceton thread was "sweat?" |
| [21:12:46] | nyloc (nyloc!~quassel@p4FE4D15F.dip0.t-ipconnect.de) has joined #mythtv | |
| [21:14:39] | _nyloc_ (_nyloc_!~quassel@p4FE4C0D4.dip0.t-ipconnect.de) has quit (Read error: Operation timed out) | |
| [21:27:08] | SteveGoodey (SteveGoodey!~steve@host86-145-235-230.range86-145.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:27:43] | stichnot: | peper03: From visual inspection (not testing), the patch looks good. While you're at it, maybe declare GetSecondsPlayed as a const method. |
| [21:30:54] | peper03: | stichnot: Yep, ok. I had noticed that too. If you're ok with it, I'll commit it as it's pretty well self-contained. It seems to work ok from the tests I did earlier. |
| [21:32:08] | stichnot: | Yes, thanks. I'll let you know if anything seems off when I use it. |
| [21:37:02] | _nyloc_ (_nyloc_!~quassel@p4FE4DBB5.dip0.t-ipconnect.de) has joined #mythtv | |
| [21:41:21] | nyloc (nyloc!~quassel@p4FE4D15F.dip0.t-ipconnect.de) has quit (Ping timeout: 252 seconds) | |
| [21:45:09] | danielk22 (danielk22!~danielk@exchange.wgen.net) has left #mythtv () | |
| [21:46:48] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has quit (Remote host closed the connection) | |
| [21:47:01] | wagnerrp: | Captain_Murdoch: merely pointing out the fact that nearly every "water cooling" install is still air-cooled |
| [21:57:46] | jasoncullen (jasoncullen!~androirc@222-152-177-50.jetstream.xtra.co.nz) has quit (Remote host closed the connection) | |
| [21:58:03] | jasoncullen (jasoncullen!~androirc@222-152-177-50.jetstream.xtra.co.nz) has joined #mythtv | |
| [22:02:33] | nyloc (nyloc!~quassel@p4FE4D25B.dip0.t-ipconnect.de) has joined #mythtv | |
| [22:06:25] | _nyloc_ (_nyloc_!~quassel@p4FE4DBB5.dip0.t-ipconnect.de) has quit (Ping timeout: 248 seconds) | |
| [22:06:52] | tonsofpcs: | I have a 'thermoplastic resin cooling' cellphone (that is still air-cooled ;) |
| [22:18:44] | bobweaver: | tonsofpcs, lucky my puppy just killed my n4 |
| [22:26:52] | wagnerrp: | thermoplastic resin cooled... is that that weird Gumbo, or Gumby, or something british from a couple years ago with a plastic heatsink? |
| [22:27:51] | wagnerrp: | some low end Atom device |
| [22:30:02] | nyloc (nyloc!~quassel@p4FE4D25B.dip0.t-ipconnect.de) has quit (Read error: Operation timed out) | |
| [22:32:13] | nyloc (nyloc!~quassel@p4FE4C2DC.dip0.t-ipconnect.de) has joined #mythtv | |
| [22:32:58] | aca20031 (aca20031!~aca@2607:5300:60:2c95::1) has quit (Quit: http://www.st0rm.net) | |
| [22:33:33] | aca20031 (aca20031!~aca@2607:5300:60:2c95::1) has joined #mythtv | |
| [22:41:05] | tonsofpcs: | wagnerrp: well, it's a water-tight dust-tight cellphone, it can't be air cooled. I'm making a guess at the plastic type. |
| [22:41:19] | tonsofpcs: | the guys I went to college with would be better at telling you what it really is |
| [22:41:39] | tonsofpcs: | (I play with wires all day, they play with plastics, metals, and woods) |
| [22:43:25] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has joined #mythtv | |
| [23:03:53] | _nyloc_ (_nyloc_!~quassel@p4FE4D364.dip0.t-ipconnect.de) has joined #mythtv | |
| [23:04:06] | NOTHING4YOU is now known as Nothing4You | |
| [23:04:31] | nyloc (nyloc!~quassel@p4FE4C2DC.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds) | |
| [23:12:44] | wagnerrp: | oh, i missed that you said cellphone |
| [23:27:23] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 240 seconds) | |
| [23:31:58] | nyloc (nyloc!~quassel@pC19F560C.dip0.t-ipconnect.de) has joined #mythtv | |
| [23:35:55] | _nyloc_ (_nyloc_!~quassel@p4FE4D364.dip0.t-ipconnect.de) has quit (Ping timeout: 264 seconds) | |
| [23:37:40] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.