| Tuesday, August 6th, 2013, 00:08 UTC | ||
| [00:08:59] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [00:09:03] | jya_: | stuartm: i haven't looked into it yet.. will do today |
| [00:20:21] | NightMonkey_ (NightMonkey_!~NightrMon@64.124.185.45) has quit (Quit: Body blow! Body blow!) | |
| [00:31:50] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has quit (Ping timeout: 240 seconds) | |
| [00:47:53] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [00:58:07] | raven_ (raven_!~raven@dslb-094-216-073-106.pools.arcor-ip.net) has joined #mythtv | |
| [01:02:19] | raven (raven!~raven@dslb-188-098-214-082.pools.arcor-ip.net) has quit (Ping timeout: 260 seconds) | |
| [01:30:41] | jya: | jpabq: the issue wasn't really that it was too much on the right… but that it was too high. |
| [01:33:25] | jya: | jpabq: you can pretty much test it all using either mythutil, or the service API (port 6547/Frontend |
| [01:35:10] | jya: | other thing a tad weird. The 2nd text line (showing the album name) is not of the same color as the rest. like you have a purple bar just for that text… is that on purpose? |
| [01:48:20] | joki (joki!~joki@p54862A3A.dip0.t-ipconnect.de) has quit (Ping timeout: 245 seconds) | |
| [01:53:46] | joki (joki!~joki@p548638DC.dip0.t-ipconnect.de) has joined #mythtv | |
| [01:55:43] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [02:10:02] | jya: | while I think it's great that we show a list of git changes in the release note. I feel that it's too prominent. many of them are mostly irrelevant, small changes or bug fixes for things introduced in 0.27 and not present in 0.26… I think it should be moved much lower in the page.. Otherwise it's only readable by techies. |
| [02:18:15] | _nyloc_ (_nyloc_!~quassel@p4FE4C542.dip0.t-ipconnect.de) has joined #mythtv | |
| [02:22:05] | nyloc (nyloc!~quassel@pC19F5311.dip0.t-ipconnect.de) has quit (Ping timeout: 245 seconds) | |
| [02:27:43] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 260 seconds) | |
| [02:28:29] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [02:47:47] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [02:47:47] | Chutt (Chutt!~ijr@76.190.199.73) has joined #mythtv | |
| [03:03:23] | skd5aner: | jya: agreed, when I did the releast notes, all I cared about is how it would read to end users. Anyone can go to github and read the full changelog. Users only care about functionality that is new and cool (and visible from their perspective) + big bug fixes. |
| [03:03:32] | skd5aner: | they don't care about the under-the-cover changes |
| [03:04:10] | skd5aner: | allbeit, the way MythTV has gone the last couple of releases – the iceberg of technical changes are significately larger under the water than above it |
| [03:04:21] | jya: | yes… could simply put a link to github for people to see the list of commits |
| [03:04:25] | skd5aner: | so – I would expect fairly few changes to actually be reflected in the release notes |
| [03:04:45] | jya: | well, that's also fine to state so... |
| [03:08:54] | skd5aner: | at the end of the day – I'm just glad that someone's picked it up after I had to give it up |
| [03:13:06] | jya: | Oh, I'm not saying it's not a great work… it's very useful and is more user friendly than github log , as it's classified by categories etc... |
| [03:13:37] | jya: | just that the release note as it is, is overwhelming, and you can't really tell what's new, what has changed… just that there's been lots of changes |
| [03:58:21] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 264 seconds) | |
| [03:59:37] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:28:19] | stichnot (stichnot!~stichnot@adsl-68-127-28-24.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [04:28:28] | stichnot (stichnot!~stichnot@adsl-68-127-28-24.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [04:28:29] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [04:35:52] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 276 seconds) | |
| [04:50:01] | stichnot (stichnot!~stichnot@216.239.45.130) has joined #mythtv | |
| [04:50:02] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [04:50:02] | stichnot (stichnot!~stichnot@216.239.45.130) has quit (Changing host) | |
| [05:52:29] | wilmoore-misc (wilmoore-misc!~wilmoore@c-67-190-17-108.hsd1.co.comcast.net) has joined #mythtv | |
| [05:58:13] | SteveGoodey (SteveGoodey!~steve@host86-151-111-43.range86-151.btcentralplus.com) has joined #mythtv | |
| [06:08:18] | SteveGoodey (SteveGoodey!~steve@host86-151-111-43.range86-151.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [06:08:21] | Seeker` (Seeker`!~cjo20@host86-178-254-220.range86-178.btcentralplus.com) has joined #mythtv | |
| [06:08:29] | Seeker` (Seeker`!~cjo20@host86-178-254-220.range86-178.btcentralplus.com) has quit (Changing host) | |
| [06:08:29] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has joined #mythtv | |
| [06:59:58] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [07:21:23] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Ping timeout: 240 seconds) | |
| [07:23:40] | stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has joined #mythtv | |
| [07:23:40] | stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has quit (Changing host) | |
| [07:23:40] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv | |
| [07:54:17] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [08:00:44] | Merlin83b (Merlin83b!~Daniel@office.34sp.com) has joined #mythtv | |
| [08:33:07] | aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has quit (Ping timeout: 276 seconds) | |
| [08:49:31] | aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has joined #mythtv | |
| [09:00:49] | raven_ (raven_!~raven@dslb-094-216-073-106.pools.arcor-ip.net) has left #mythtv ("Verlassend") | |
| [09:07:08] | len (len!~quassel@75-161-179-129.mpls.qwest.net) has quit (Remote host closed the connection) | |
| [09:36:40] | jya: | stuartm: the issue with your mp3 is that it contains a mjpeg stream… myth sees that as a video and is trying to sync audio and video… and so it starts just dropping audio to keep up |
| [09:37:03] | stuartm: | it does? |
| [09:37:52] | stuartm: | it contains a jpeg – the coverart, is ffmpeg mis-identifying this as an mjpeg video stream? |
| [09:38:19] | jya: | well, using ffmpeg (stock) this is a video mjpeg stream |
| [09:38:27] | aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has quit (Read error: Operation timed out) | |
| [09:38:30] | stuartm: | and is that what is causing problems playing back in mythmusic too? |
| [09:38:40] | jya: | it plays fine for me in mythmusic |
| [09:38:53] | jya: | mythmusic only look at the audio stream |
| [09:39:03] | jya: | so it doesn't matter what other streams are there |
| [09:39:43] | stuartm: | for me, in mythmusic it plays, but with a static – that's the problem I opened the ticket about, not so bothered about being able to play mp3s through mythavtest |
| [09:40:09] | stuartm: | and that's the problem Paul is able to reproduce, even with radio streams |
| [09:40:19] | jya: | do you hear static during the whole song or just sometimes? |
| [09:41:59] | stuartm: | with that particular track it starts fine, then starts to become apparent further in, first hint is around 14 seconds iirc, but it's most noticeable from around the 40 second mark |
| [09:42:00] | jya: | can you start mythfrontend with -v audio,playback,libav --loglevel=debug ; play that file via mythmusic and post the output on the ticket? |
| [09:42:16] | jya: | maybe I should listen to it for longer then... |
| [09:42:30] | stuartm: | it's always the same tracks and always at the same points |
| [09:42:55] | stuartm: | I did post that log a few days ago, let me find it ... |
| [09:43:27] | jya: | it's in the ticket? |
| [09:44:13] | stuartm: | http://pastebin.com/7Jm6JcsL |
| [09:44:24] | jya: | well, no static here... |
| [09:44:38] | stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has quit (Ping timeout: 264 seconds) | |
| [09:45:54] | stuartm: | http://irc.mythtv.org/ircLog/channel/4/2013-08-01:11:09 |
| [09:46:00] | jya: | you have a very weird audio configuration there.. |
| [09:46:09] | jya: | your card doesn't support 16 bits audio playback |
| [09:46:12] | jya: | never seen that before |
| [09:47:02] | jya: | ever tried to play it using 0.26? |
| [09:47:36] | stuartm: | I can do – give me a few minutes |
| [09:48:31] | jya: | wonder if it's something to do with the float conversion… my system supports 16 bits audio, and 44kHz, so there's no resampling or format conversion happening on my system |
| [09:49:13] | jya: | still puzzled on what you have running for a nvidia cards not supporting 16 bits audio |
| [09:49:18] | jya: | what card is that? |
| [09:49:50] | jya: | need to think on what I can do to simulate your setup so I enter the same code |
| [09:52:18] | stuartm: | onboard an ASUS M3N78 mobo, NVIDIA Corporation MCP72XE/MCP72P/MCP78U/MCP78S High Definition Audio using the snd_hda_intel driver |
| [09:53:05] | jya: | then that should support 16 bits audio... |
| [09:53:35] | jya: | anyhow… I've forced the float conversion to occur on my system, and I'm still not hearing any static |
| [09:53:41] | jya: | got to force the resampler then |
| [09:54:11] | aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has joined #mythtv | |
| [09:54:42] | jya: | would need to see paul-h logs… see what's going on with him if he too hears static on that particular file… very unlikely to have another cards not supporting 16 bits audio |
| [09:57:31] | stuarta (stuarta!~stuarta@callisto.squashedfrog.net) has joined #mythtv | |
| [09:57:32] | stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has joined #mythtv | |
| [09:57:32] | stuarta (stuarta!~stuarta@callisto.squashedfrog.net) has quit (Changing host) | |
| [10:00:49] | jya: | well, with exact same resampling settings as yours (44kHz -> 48kHz), 16 bits -> 32 bits conversion enabled it plays fine… I'm not using ALSA nor do I use volume mixer… but I doubt this would cause static… but just in case, can you disable volume control? |
| [10:12:41] | stuartm: | can still reproduce with volume controls disabled |
| [10:13:27] | stuartm: | just about to test 0.26 |
| [10:13:32] | jya: | ok |
| [10:13:44] | jya: | doubt you'll hear a difference… but you never know |
| [10:14:21] | jya: | I've changed the S16->float conversion to be going from -127,127 to -128,127 |
| [10:14:50] | jya: | only thing that changed in regards to audio between .26->.27 |
| [10:19:52] | stuartm: | I can't reproduce with 0.26, exactly the same hardware but different distro/kernel |
| [10:20:22] | stuartm: | I never noticed the problem on this machine with 0.26 though |
| [10:20:25] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [10:22:34] | stuartm: | plays just fine with other apps e.g. ffplay |
| [10:24:40] | jya: | is that the same machine you run with 0.27 normally? |
| [10:26:35] | stuartm: | the 0.26 test? No, identical machine that I run 0.26 on in production only difference is that it runs Ubuntu instead of Mageia – testing 0.26 locally is doable but it will take a while to setup |
| [10:26:53] | jya: | would be interesting to do so... |
| [10:27:16] | jya: | then that exclude any possibilities… and from that point on, a git bisect is the way to go :) |
| [10:29:06] | stuartm: | I could more easily upgrade the production box to 0.27 which would provide the same confirmation? |
| [10:34:57] | wilmoore-misc (wilmoore-misc!~wilmoore@c-67-190-17-108.hsd1.co.comcast.net) has quit (Remote host closed the connection) | |
| [11:17:29] | dekarl1 (dekarl1!~dekarl@p4FE850A7.dip0.t-ipconnect.de) has joined #mythtv | |
| [11:19:43] | dekarl (dekarl!~dekarl@p4FCEF79F.dip0.t-ipconnect.de) has quit (Ping timeout: 260 seconds) | |
| [11:29:35] | stuartm: | jya: looks like it is a driver bug after all, upgraded my production box to 0.27 and I can't reproduce, so I guess I'm looking at a switching to another kernel |
| [11:31:17] | stuartm: | although it's strange that only mythtv is affected and not other applications |
| [11:31:30] | stuartm: | I'm running 3.8.13.4 |
| [11:31:57] | stuartm: | alsa 1.0.25 |
| [11:33:09] | stuartm: | oops, 1.0.26 |
| [11:33:20] | stuartm: | production machine is on 1.0.25 |
| [12:42:47] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [12:50:27] | Tobbe5178: | is there a way to speed up the initial start of eit scanning? |
| [12:50:34] | Tobbe5178: | for testing purposes |
| [12:50:59] | Tobbe5178: | not fun to have to wait 5+ minutes every time i want to test |
| [12:53:41] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [13:12:19] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [13:12:25] | stuarta: | Tobbe5178: iirc it's a constant somewhere |
| [13:15:02] | Tobbe5178: | ok |
| [13:15:08] | Tobbe5178: | it seems a bit random |
| [13:15:20] | Tobbe5178: | sometimes i have waited over 15 minnutes without any data |
| [13:15:30] | Tobbe5178: | and sometimes it takes only 5 or 10 minutes |
| [13:15:44] | stuarta: | it depends a *lot* on which mux gets picked |
| [13:15:57] | stuarta: | some muxes carry a lot of data, others carry very little |
| [13:16:14] | Tobbe5178: | true, forgot about that |
| [13:25:05] | wolfgang4 (wolfgang4!~wolfgang@178-27-196-33-dynip.superkabel.de) has quit (Ping timeout: 264 seconds) | |
| [13:27:27] | stuarta: | Tobbe5178: ah, i just remembered the other way to force it. LiveTV! |
| [13:27:46] | Tobbe5178: | that might work |
| [13:27:51] | stuarta: | if you watch livetv on the channel carrying the EIT data you are interested in, it'll passively collect |
| [13:28:04] | stuarta: | it does, done it before many times |
| [13:28:14] | Tobbe5178: | only small problem is that i'm running my dev box under kvm |
| [13:28:29] | Tobbe5178: | with a usb dvb tuner stick |
| [13:28:34] | wolfgang4 (wolfgang4!~wolfgang@178-27-196-33-dynip.superkabel.de) has joined #mythtv | |
| [13:28:45] | Tobbe5178: | not sure if i can start livetv but will give it a try |
| [13:28:51] | wolfgang4 (wolfgang4!~wolfgang@178-27-196-33-dynip.superkabel.de) has quit (Client Quit) | |
| [13:30:08] | wolfgang (wolfgang!~wolfgang@178-27-196-33-dynip.superkabel.de) has joined #mythtv | |
| [13:30:23] | Tobbe5178: | my additions to the eit collection is almost working |
| [13:30:51] | Tobbe5178: | with one exception, my seriesid value that comes from a 4 byte value always ends up being 1 |
| [13:30:55] | Tobbe5178: | when it is not supposed to |
| [13:34:07] | danielk221: | There is a setting in mythtv-setup somewhere..(I think in general) you can change the default down to about a minute there, or muck with the DB to get it lower. |
| [13:34:28] | danielk221: | You can change both how long until it starts scanning and how long it spends on each mux. |
| [13:38:49] | stuarta: | yes that is also true |
| [13:40:28] | Tobbe5178: | what is the difference between seriesid and programid? |
| [13:40:42] | Tobbe5178: | i assume the first one is used to tell what shows is part of the same series |
| [13:47:09] | stuarta: | yes, seriesid should be the same for every episode in a series, and the programid should be different for every episode |
| [13:47:10] | sphery: | Tobbe5178: yes, seriesid is a unique identifier of a given series... ideally provided by the guide service (because they know if 2 shows with the same title are actually related--i.e. they know a difference between Battlestar Galactica (original) and Battlestar Galactica (re-imagined)) |
| [13:47:16] | stichnot (stichnot!~stichnot@216.239.45.130) has joined #mythtv | |
| [13:47:16] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [13:47:16] | stichnot (stichnot!~stichnot@216.239.45.130) has quit (Changing host) | |
| [13:47:32] | sphery: | in our xmltv grabber, though, we will generate a series id by hashing the title |
| [13:47:40] | Tobbe5178: | ok |
| [13:47:52] | Tobbe5178: | so if i can get seriesid over eit then that is a good thing |
| [13:48:07] | Tobbe5178: | can someone see any error in this pice of code: |
| [13:48:08] | Tobbe5178: | uint32_t _seriesid=((uint32_t)_data[3] << 24) | ((uint32_t)_data[4] << 16) | ((uint32_t)_data[5] << 8) || _data[6]; |
| [13:48:12] | sphery: | Tobbe5178: programid should only be specified if you /know/ for sure exactly which episode it is--because having a programid means that the user-specified duplicate matching technique is ignored |
| [13:48:26] | Tobbe5178: | why do this produce 1 when the value is converted to a qstring and printed? |
| [13:48:40] | Tobbe5178: | aha |
| [13:48:51] | Tobbe5178: | so thats why some of the dupe matching is screwed up |
| [13:49:03] | sphery: | in our xmltv grabber, if no programid is provided but the listings service specifies a season and episode number, we generate a programid, basically using the seriesid, season number, and episode number |
| [13:49:06] | Tobbe5178: | but doesnt mythfilldatabase also fill inn programid ? |
| [13:49:43] | Tobbe5178: | becase on my prod system i have for example seriesid=245772770 and programid=EP24577277026 |
| [13:49:52] | Tobbe5178: | basicly just EP added |
| [13:50:14] | sphery: | yes, mythfilldatabase will generate as I've described above |
| [13:50:15] | Tobbe5178: | also programid somtimes have characters a-z at the end too |
| [13:50:37] | sphery: | that's what I meant by our xmltv grabber--maybe I should have said "xmltv reader"? |
| [13:51:28] | Tobbe5178: | isnt it a bit confusing then to have a dupe matching if it is not taken into concideration? |
| [13:52:24] | sphery: | all that matters for programid is that any given episode of any show has a unique programid (unique among all shows in all series--no duplicates, ever) and that episode should /always/ have the same programid, regardless of when it airs again in the future |
| [13:52:51] | Tobbe5178: | ok |
| [13:53:59] | sphery: | No, because programid is, by definition, the definitive identifier of a program. So, if provided, it will /always/ be used. The user-specified duplicate matching mechanism is what's used when better information isn't available (i.e. what to use when guessing) |
| [13:55:10] | sphery: | it's better for EIT or xmltv code to not provide a programid than to provide ones that can't be guaranteed to follow the requirements (each program/episode gets a unique value and each re-airing of a program gets the exact same value) |
| [13:55:27] | sphery: | i.e. if you don't have a definitive identifier, don't provide programid :) |
| [13:55:35] | Tobbe5178: | ok |
| [13:55:47] | Tobbe5178: | then i'll just insert the seriesid |
| [13:55:58] | sphery: | are you given an ID by your EIT data? |
| [13:56:01] | Tobbe5178: | yes |
| [13:56:05] | sphery: | if so, you can use that (assuming you trust it) |
| [13:56:23] | Tobbe5178: | in a custom descriptor in the eit table sent by the broadcaster |
| [13:56:32] | sphery: | or else you can try doing something like the XMLTV-reading code does and use something else you trust (like season/episode number) |
| [13:57:15] | Tobbe5178: | it includes, season, episode, episode total, production year and some other info like credits, director, production country and spoken lang |
| [13:57:41] | Tobbe5178: | i got most of it working but all i get for seriesid is a 1 |
| [13:58:01] | Tobbe5178: | how hard can it be to read a 32 bit number and then convert it to a qstring |
| [14:00:40] | Tobbe5178: | the previouslyshown flag, is that just informational or something the scheduler takes into consideration? |
| [14:01:42] | sphery: | scheduler takes it into consideration for new-episodes-only or no-repeats filters |
| [14:02:00] | sphery: | again, don't set it unless you know it's right--it's not required |
| [14:02:30] | sphery: | though if you don't set it and you don't set original air date, those filters won't work for your users |
| [14:10:23] | Tobbe5178: | stupid mistake, i had written || instead of | |
| [14:10:49] | Tobbe5178: | no wonder i get 1 all the time |
| [14:10:51] | sphery: | hehe, that would do it :) |
| [14:11:56] | wolfgang (wolfgang!~wolfgang@178-27-196-33-dynip.superkabel.de) has quit (Ping timeout: 256 seconds) | |
| [14:17:21] | wolfgang (wolfgang!~wolfgang@178-27-196-33-dynip.superkabel.de) has joined #mythtv | |
| [14:30:47] | Tobbe5178: | how is partnumber/parttotal different than syndicatedepisodenumber ? |
| [14:31:11] | Tobbe5178: | is that used for multipart programs? |
| [14:31:25] | Tobbe5178: | that not nessesarily is counted as a series |
| [14:40:10] | wolfgang (wolfgang!~wolfgang@178-27-196-33-dynip.superkabel.de) has quit (Read error: Operation timed out) | |
| [14:41:03] | Tobbe5178: | hmm, aparently the spec allows the seriesid i got to be reused 91 days after the end of last scheduled event in that series |
| [14:43:04] | Tobbe5178: | and i also need to add a bit more to the seriesid to make it unique |
| [14:43:37] | Tobbe5178: | <original_network_id>.[<transport_stream_id>].<service_id>;< ;series_id> or <original_network_id>.[<transport_stream_id>].<service_id>;< ;series_id>.<season>.<episode> for a specific episode |
| [14:49:01] | wilmoore-misc (wilmoore-misc!~wilmoore@c-67-190-17-108.hsd1.co.comcast.net) has joined #mythtv | |
| [14:52:45] | sphery: | Tobbe5178: yes, partnumber/parttotal is used for things like mini-series (i.e. 2-part or 4-part made-for-TV type movies) |
| [14:53:45] | sphery: | Tobbe5178: also, syndicatedepisodenumber is /not/ episode number... it's a production-company-specified identifier for the episode that has no specific format or meaning--it's informational and should only be provided if you actually have the value the production company used |
| [14:56:15] | sphery: | sometimes they use numeric values (sometimes simple counters, sometimes <season#><episode#>, sometimes other), sometimes it's alphanumeric (like RS036 or 845A or MI11026 or 1308101W or 1ABF03 or 7AJN13 ...), and it can even be purely alpha |
| [14:56:24] | wolfgang (wolfgang!~wolfgang@178-27-196-33-dynip.superkabel.de) has joined #mythtv | |
| [14:57:02] | tonsofpcs: | or it could be a placeholder because they didn't have the actual episode # airing in time for the metadata handling service |
| [14:57:04] | sphery: | again, only specify it if you're actually given the actual value from the production company |
| [14:57:15] | sphery: | but it's /not/ a simple episode number |
| [14:57:53] | sphery: | and can't be derived from any other data |
| [14:59:05] | sphery: | Tobbe5178: if your guide service's series ID's aren't guaranteed to be unique and consistent for all future showings, you shouldn't use them at all... you're better off doing like mfdb and generating one |
| [15:00:15] | sphery: | or you can leave it blank... if you generate one using title, some would argue it's actually worse than leaving it blank |
| [15:01:43] | sphery: | but if you generate it from title, please do so using the same ELF hash algorithm we use in mfdb |
| [15:03:11] | sphery: | tonsofpcs: syndicatedepisodenumber shouldn't get placeholder values, ever, since it's not related to episode number... it should always be blank if not known when the listings are created |
| [15:04:20] | tonsofpcs: | sphery: you're awful trusting of the listing agencies. Having dealt with them, I'm not ;) |
| [15:10:06] | sphery: | probably better to say I have very high expectations of listings services (since mine--SD/TMS--sets the bar /very/ high :) |
| [15:17:40] | wilmoore-misc (wilmoore-misc!~wilmoore@c-67-190-17-108.hsd1.co.comcast.net) has quit (Remote host closed the connection) | |
| [15:27:04] | stuarta: | Tobbe5178: in the uk at least, the seriesid & programid include the default authority which is either part of the channel (in the SDT) or part of the mux itself |
| [15:35:48] | stuartm: | default authority looks like a domain name e.g. bbc.co.uk |
| [15:36:14] | stuartm: | so the full programid because bbc.co.uk/12345678 |
| [15:36:19] | stuartm: | becomes |
| [15:42:03] | stuartm: | Tobbe5178: SELECT default_authority FROM channel WHERE default_authority != ''; |
| [15:43:30] | stuartm: | if you've rescanned in the last couple of years and the default authority is included by your broadcasters, then it should be in the channel table – if so then you can prepend it to the seriesid to get a unique value as is already done for other countries |
| [15:45:32] | stuartm: | jya: so I know where to look, which version of alsa are you using? |
| [15:47:56] | stichnot (stichnot!~stichnot@216.239.45.130) has joined #mythtv | |
| [15:47:56] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [15:47:56] | stichnot (stichnot!~stichnot@216.239.45.130) has quit (Changing host) | |
| [15:55:31] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG) | |
| [16:08:06] | Tobbe5178: | default_authority is probably part of CRID that i see being referenced in the spec from time to time but unfortunately it is not being transmitted |
| [16:08:40] | Tobbe5178: | and my dev box was setup from scratch just a few days ago, so it got a clean install with clean channel scan and no default_authority |
| [16:09:35] | stuarta: | okay, not very helpful if they don't broadcast it |
| [16:11:23] | Tobbe5178: | i wonder if i can realy use the series id at all |
| [16:11:40] | Tobbe5178: | because if i remeber correctly a serviceid is the same as a specific channel |
| [16:12:09] | Tobbe5178: | i need to check some series that is being transmitted on multiple channels and see what i get |
| [16:12:36] | SteveGoodey (SteveGoodey!~steve@host86-151-111-43.range86-151.btcentralplus.com) has joined #mythtv | |
| [16:13:48] | Tobbe5178: | yes, the seriesid i got is just crap |
| [16:14:07] | Tobbe5178: | 5 different seriesid for one series |
| [16:14:14] | stuarta: | start complaining :) |
| [16:14:27] | Tobbe5178: | there is so much to complain about... |
| [16:14:55] | Tobbe5178: | they put the first part of the description in the event text in the short event descriptor and then continue it in the extended event descriptor |
| [16:15:05] | Tobbe5178: | this screws up the subtitles by default |
| [16:15:48] | Tobbe5178: | everyone else uses the shortevent descriptor as title and subtitle |
| [16:15:56] | Tobbe5178: | then the extended one becomes the description |
| [16:17:40] | Tobbe5178: | lol, i got different seriesid for same episode too :) |
| [16:25:58] | Gibby (Gibby!~Gibby@184.170.249.223) has quit (Read error: Connection reset by peer) | |
| [16:25:58] | rsiebert_ (rsiebert_!~quassel@g226063111.adsl.alicedsl.de) has joined #mythtv | |
| [16:28:45] | rsiebert (rsiebert!~quassel@e179133003.adsl.alicedsl.de) has quit (Ping timeout: 245 seconds) | |
| [16:28:54] | wilmoore-misc (wilmoore-misc!~wilmoore@vlandnat.mystrotv.com) has joined #mythtv | |
| [16:30:18] | Gibby (Gibby!~Gibby@184.170.249.223) has joined #mythtv | |
| [16:35:47] | sphery: | Tobbe5178: yeah, you may need to create fixups for things like the subtitle/description issue--there are some already in there you can look at and either enable or use as a template |
| [16:35:55] | sphery: | fixups = eit fixups |
| [16:36:19] | sphery: | and it does sound like you should ignore the seriesid they give and either leave it blank or generate one from title using an ELF hash as in mfdb |
| [16:38:32] | stichnot (stichnot!~stichnot@216.239.45.77) has joined #mythtv | |
| [16:38:33] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [16:38:33] | stichnot (stichnot!~stichnot@216.239.45.77) has quit (Changing host) | |
| [16:46:24] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Read error: Operation timed out) | |
| [16:47:13] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
| [16:53:34] | kenni (kenni!~kenni@mythtv/developer/kenni) has quit (Quit: leaving) | |
| [16:53:56] | Merlin83b (Merlin83b!~Daniel@office.34sp.com) has quit (Quit: Leaving) | |
| [17:04:12] | Chutt (Chutt!~ijr@76.190.199.73) has quit (Read error: Connection reset by peer) | |
| [17:06:57] | dekarl1 is now known as dekarl | |
| [17:20:09] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv | |
| [17:46:01] | dekarl: | Tobbe5178: I'll happily review a patch that handles the guide service hint. (I need to look the correct name/details up, but somewhere there is a hint on which transport contains the EIT for all channels) Starting the EIT scan there should speed up the guide collection by a lot. |
| [17:47:06] | Tobbe5178: | well... |
| [17:47:28] | Tobbe5178: | not sure i can find that data |
| [17:47:41] | Tobbe5178: | but i did find a reference to EIT+ data on one pid |
| [17:47:51] | Tobbe5178: | but when i tried to dump it with dvbsnoop i got nothing |
| [17:48:01] | Tobbe5178: | but according to dvbtraffic there should be data there |
| [17:49:26] | dekarl: | EIT+? |
| [17:49:31] | Tobbe5178: | yes |
| [17:49:43] | Tobbe5178: | aparently my provider sends EIT+ |
| [17:50:16] | Tobbe5178: | in the NIT there is a special descriptor that points to a service on a different pid where you can find EIT+ data |
| [17:50:40] | Tobbe5178: | if i understand it right, it is supposed to be normal EIT data but with better quality and/or more data |
| [17:50:53] | Tobbe5178: | but it is most likely encrypted by with the CA module |
| [17:51:07] | Tobbe5178: | and i think thats why i never saw any data when i experimented with dvbsnoop |
| [17:51:17] | dekarl: | quite possible, as EIT data may be encrypted |
| [17:51:28] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [17:51:48] | aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has quit (Ping timeout: 256 seconds) | |
| [17:57:58] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv | |
| [18:04:58] | aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has joined #mythtv | |
| [18:09:58] | stuartm: | also just possible that it's not encoded, but compressed like the Freesat EIT data |
| [18:10:15] | stuartm: | not encrypted, but encoded |
| [18:10:29] | stuartm: | e.g. huffman |
| [18:26:12] | NightMonkey (NightMonkey!~NightrMon@64.124.185.45) has joined #mythtv | |
| [18:26:12] | NightMonkey (NightMonkey!~NightrMon@64.124.185.45) has quit (Changing host) | |
| [18:26:12] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [18:30:44] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv | |
| [18:35:52] | Tobbe5178: | can someone tell me what the difference is between AUD_DOLBY and AUD_SURROUND ? |
| [18:36:16] | Tobbe5178: | the reason for the question is that the code is using it in 2 different ways |
| [18:38:13] | tonsofpcs: | I imagine that AUD_DOLBY is Dolby encoded audio and AUD_SURROUND is Surround... |
| [18:39:45] | Tobbe5178: | thats what i also thought but... |
| [18:40:19] | Tobbe5178: | in libs/libmythtv/mpeg/dvbdescriptors.h ComponentDescriptor::AC3Properties |
| [18:40:25] | Tobbe5178: | case 0x4: case 0x5: |
| [18:40:26] | Tobbe5178: | properties |= AUD_SURROUND; |
| [18:40:26] | Tobbe5178: | break; |
| [18:40:37] | Tobbe5178: | case 4 & 5 is for multi channel audio |
| [18:40:46] | Tobbe5178: | 4 is >2 channels and 5 is >5 |
| [18:41:22] | Tobbe5178: | and in mythfilldatabase AUD_DOLBY is used for dolby digital and AUD_SURROUND for surround |
| [18:42:02] | danielk221: | surround is probably more useful to the end user than 'DOLBY' since there are so many Dolby encodings from mono up to surround sound. |
| [18:42:39] | Tobbe5178: | yes |
| [18:42:59] | Tobbe5178: | but shoudlt mythfilldatabase be consistent with the componentdescriptor? |
| [18:43:04] | Tobbe5178: | so they agree on what is what? |
| [18:43:58] | danielk221: | It sounds like they are consistent to me. Dolby digital implies that it is a Dolby encoding, but not that it is surround. |
| [18:44:44] | Tobbe5178: | hmm, ok |
| [18:45:10] | Tobbe5178: | i was thinking of dolby surround as the old analog surround sound |
| [18:45:25] | Tobbe5178: | and not multichannel dolby digital |
| [18:46:10] | dekarl: | isn't "surround" the good old 2 channel phase shift encoded stuff? |
| [18:46:19] | Tobbe5178: | exactly |
| [18:46:24] | danielk221: | Ah, I don't think we see that much, and if we do we probably treat it as stereo. |
| [18:46:56] | danielk221: | Mostly we see AC3 or one of the MPEG audio codecs. |
| [18:48:18] | Tobbe5178: | the reason i found this was because all of my programs with 5.1 audio is flaged as stereo |
| [18:48:35] | Tobbe5178: | i think this is due to bad data from the provider |
| [18:48:42] | danielk221: | Which guide data provider? EIT? |
| [18:48:45] | Tobbe5178: | eit |
| [18:49:58] | danielk221: | We have EIT fixup algorithms specific to providers to address those types of issues. I haven't looked at that code in years so I don't know if it would cover this or not. |
| [18:51:34] | Tobbe5178: | i'll just put something in the eitfixup routine and parse the description |
| [18:52:08] | Tobbe5178: | just got a bit confused about the AUD_SURROUND vs AUD_DOLBY usage in ContentDescriptor |
| [18:52:13] | Tobbe5178: | i think it is backwards |
| [18:52:24] | Tobbe5178: | and mythfilldatabase usage is correct |
| [18:53:17] | danielk221: | That could very well be. You can download up to 3 of those DVB specs for free to verify... |
| [18:54:33] | Tobbe5178: | i just googled a bit and found: http://www.etsi.org/deliver/etsi_en/300400_30 . . . v010901p.pdf and then on page 101 i compared that to what is being used in ContentDescriptor::AC3Properties |
| [18:55:49] | Tobbe5178: | something completely different, is there any known issues with mythweb and php 5.5 ? |
| [18:56:01] | Tobbe5178: | because translation system is completely broken |
| [18:56:20] | Tobbe5178: | and it errors in a few places |
| [19:07:50] | stuartm: | ideally once recorded, the audio, video and subtitle metadata would be based on the actual recording and not the guide data |
| [19:08:16] | stuartm: | since what is actually broadcast can vary from what the guide indicates |
| [19:13:26] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!) | |
| [19:23:41] | dekarl: | Tobbe5178: there is a newer version, its even properly linked at http://de.wikipedia.org/wiki/Event_Information_Table |
| [19:29:32] | len_ (len_!~quassel@75-161-179-129.mpls.qwest.net) has joined #mythtv | |
| [19:57:53] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit (Quit: Some days I get depressed at the end of an alien invasion movie when the earthlings win.) | |
| [20:53:28] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 276 seconds) | |
| [21:02:42] | stuarta: | well that's 0.27 alpha built on the prod frontend... |
| [21:04:43] | stuarta: | and the prod backend. \o/ i can test it once the wifey is off the tv |
| [21:10:03] | SteveGoodey (SteveGoodey!~steve@host86-151-111-43.range86-151.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:18:20] | aca20031 (aca20031!~aca@2607:5300:60:2c95::1) has quit (Ping timeout: 245 seconds) | |
| [21:19:45] | aca20031 (aca20031!~aca@2607:5300:60:2c95::1) has joined #mythtv | |
| [21:26:38] | aca20031 (aca20031!~aca@2607:5300:60:2c95::1) has quit (Ping timeout: 240 seconds) | |
| [21:26:46] | aca20031 (aca20031!~aca@2607:5300:60:2c95::1) has joined #mythtv | |
| [22:08:30] | gigem: | Does anyone know why my backend keeps "Starting mythlogserver" every 30 seconds? |
| [22:12:05] | jya: | stuartm: could still be something your particular configuration was triggering. And paul-h says he's seeing the issue. I'll keep investigating. I'll also try to find a fix so an invalid mjpeg stream doesn't screwup playback |
| [22:15:04] | jya: | stuartm: I'm using ubuntu 12.04 which ships with alsa 1.0.24 and kernel 3.2.0 |
| [22:20:34] | stuartm: | well, although I'm not ruling out a difference in mythtv configuration between my production and development boxes they are as far as I'm aware identical except for the versions of alsa and the kernel |
| [22:21:26] | stuartm: | if Paul is running 1.0.26 or a recent kernel, then maybe that's relevant, at the very least it's worth ruling in or out |
| [22:22:48] | stuartm: | my production box is running 12.10 which includes 1.0.25, so if the problem is with alsa or our interaction with alsa then it has to be with 1.0.26 specifically |
| [22:24:31] | stuartm: | I'll grab an -v audio log from the production box tomorrow so I can compare the two configurations |
| [22:45:14] | jpabq: | jya: I guess I don' |
| [22:46:04] | jpabq: | jya, I guess I don't understand what you are asking for, with the fullscreen notification window. I thought you were complaining that the info box covered up the album artwork, and that should not happen now... |
| [22:47:56] | paul-h (paul-h!~Paul@176.253.145.244) has joined #mythtv | |
| [22:50:15] | paul-h: | stuartm, jya: I'm using alsa 1.0.26 on a 3.5.3 kernel |
| [22:53:48] | stuartm: | paul-h: what audio hardware and/or driver? ATM, the alsa version is looking most relevant, you're using a different kernel and if you're also using a different chip that would rule out the driver completely |
| [22:56:03] | paul-h: | This is from lspci – 00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) |
| [22:57:55] | paul-h: | Driver could be snd_hda_intel |
| [22:58:11] | stuartm: | different chipset, same driver though |
| [23:00:34] | paul-h: | I'll rollback to 1.0.25 to see if the problem goes away but that will have to wait till tomorrow just in the middle of something I need to finish tonight |
| [23:02:22] | stuartm: | thanks, not so easy to rollback here since 1.0.25 isn't the repos for Mageia 3 |
| [23:02:22] | paul-h: | I've been using 1.0.26 since December and only recently noticed the problem so I'm sure it's a regression though |
| [23:02:51] | paul-h: | I hope gentoo still has an ebuild for it |
| [23:03:07] | stuartm: | if it is 1.0.26, then it's probably something to do with the way we're interacting with it than a bug in ALSA itself |
| [23:05:31] | paul-h: | AFAICT it only affects Myth so you could be right |
| [23:10:40] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 264 seconds) | |
| [23:14:16] | paul-h (paul-h!~Paul@176.253.145.244) has quit (Quit: Konversation terminated!) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.