Jump to content

Channel List Editor various UX issues


tim copperfield

Recommended Posts

So, I've been using DVBViewer to organize a (non-English) satellite mux and had to do a fair bit of editing in the channel editor.

 

Here are some issues that I've found which make editing non-intuitive and sometimes outright destructive.

 

1) editing a channel (clicking left-side tree view, editing stuff on the right side) then moving to another channel without clicking apply immediately discards all changes without warning.

2) editing a channel and clicking apply doesn't actually save the channel file (if the app crashes during editing like it did for me, all changes are lost). I know there's a 'save' icon on the bottom but its not intuitive.

3) Switching to bold font when double-clicking a channel name on the left treeview keeps the selection bar same size as pre-bold and truncates the text visually. Clicking off to another channel and returning to the previous one again makes the selection bar correct size again.

4) Related to 3), after editing a channel name and making it longer or shorter remains the selection bar the size of pre-edit version and it looks ugly. Needs a focus on/off from the channel to fix.

5) If you edit a bunch of channels while hitting apply and close the window, the changes are saved. This makes the "save" button redundant but only in the case of when the app doesn't crash during the editing session.

6) If you slow-double-click channel name on the left treeview to edit, changes are applied when focusing to another channel. This contradicts with the "apply" button usage.

7) Pressing ESC disappears the dialog, even if there are unsaved changes, BUT if you've been diligently pressing Apply and the app didn't crash, the changes are saved.

 

Link to comment
16 hours ago, tim copperfield said:

I've been using DVBViewer to organize a (non-English) satellite mux and had to do a fair bit of editing in the channel editor.

 

Why? Usually there isn't much to enter/apply in the Channel Editor, except small corrections in rare cases. Scanning should retrieve all required data. If the reception parameters and the Service ID are present, the automatic channel update fills in/corrects all PIDs on tuning (provided a PAT and PMT are broadcasted). 

 

16 hours ago, tim copperfield said:

editing a channel (clicking left-side tree view, editing stuff on the right side) then moving to another channel without clicking apply immediately discards all changes without warning.

 

A matter of taste. Personally I don't like software that interrupts my workflow by prompting again and again for confirmation. It should rather assume that the user knows what he does and only display a warning if a lot of data can get lost, e.g. a whole part of the channel list.

 

16 hours ago, tim copperfield said:

editing a channel and clicking apply doesn't actually save the channel file

 

It isn't supposed to. Saving the channel list disables the possibility to undo changes by reloading the channel list.

 

16 hours ago, tim copperfield said:

Switching to bold font when double-clicking a channel name on the left treeview keeps the selection bar same size as pre-bold and truncates the text visually (...) after editing a channel name and making it longer or shorter remains the selection bar the size of pre-edit version and it looks ugly.

 

Thanks for the hint. The underlying treeview component does not repaint itself properly in some situations. It requires additional invalidate/repaint commands in the application code. The Favourites Editor is also affected. Will be fixed in the next release.

 

16 hours ago, tim copperfield said:

If you edit a bunch of channels while hitting apply and close the window, the changes are saved.

 

The channel list gets saved when DVBViewer closes, not when the Channel Editor is closed.

 

16 hours ago, tim copperfield said:

If you slow-double-click channel name on the left treeview to edit, changes are applied when focusing to another channel. This contradicts with the "apply" button usage.

 

IMO that's normal Windows behaviour.

 

Link to comment
On 11/7/2021 at 5:02 PM, Griga said:

Why? Usually there isn't much to enter/apply in the Channel Editor, except small corrections in rare cases. Scanning should retrieve all required data. If the reception parameters and the Service ID are present, the automatic channel update fills in/corrects all PIDs on tuning (provided a PAT and PMT are broadcasted). 

Do you *really* have to ask this? DVBViewer does not handle utf8/unicode ISDB-T service names, so they all come up as garbage letters, and even if it did, in the other threads I replied, the channel info is saved as ASCII so I'd have to edit it to translate anyway.

 

On 11/7/2021 at 5:02 PM, Griga said:

only display a warning if a lot of data can get lost, e.g. a whole part of the channel list.

I wish I was warned about the loss of my work before DVBViewer crashed.

 

On 11/7/2021 at 5:02 PM, Griga said:

IMO that's normal Windows behaviour.

I agree, but as I said, that also contradicts with your "apply button" press requirement when moving off to another item in treeview.

Why is editing a channel name auto-applied, but changing something inside the dialog and moving on to next channel auto-rejected?

 

On 11/7/2021 at 5:02 PM, Griga said:

The channel list gets saved when DVBViewer closes, not when the Channel Editor is closed.

This is even worse then, because that's how I lost about 30 minutes worth of renaming, when DVBViewer crashed while I was editing the channel list. If you edit, CLOSE the channel list, and there's no indication it hasn't been saved, that's terrible UX. Because if for some reason the user "forgets" (or isn't even aware of) the "save" button, they can end up with changes lost if/when the app crashes or maybe terminated improperly some hours/days later.

 

Link to comment
On 11/9/2021 at 10:05 AM, tim copperfield said:

Do you *really* have to ask this?

 

Of course. Without knowing your usage scenario I can't determine if and how problems can be solved. Please note that I have no possibility to receive ISDB broadcasts and to check/test how it works, except with a few samples on my hard disk. Handling exotic stuff completely depends on user feedback. It requires cooperative users from that region, who provide samples / transponder dumps, for example, and are able to test the results of changes.

 

On 11/9/2021 at 10:05 AM, tim copperfield said:

DVBViewer does not handle utf8/unicode ISDB-T service names

 

AFAIK ISDB service names are not Unicode. ISDB is using specific character sets with names like GS_KANJI, GS_HIRAGANA, GS_KATAKANA, GS_LATIN_EXTENSION etc. However, DVBViewer converts them to UTF-8. This at least applies to EPG data and ISDB subtitles.

 

On 11/9/2021 at 10:05 AM, tim copperfield said:

the channel info is saved as ASCII

 

Wrong. DVBViewer uses the Windows API to convert channel names to the local character set. On a PC configured for Japanese locale this would be SHIFTJIS_CHARSET (code page 932). Would this cover your needs?

 

However, a code research revealed, that in contrast to EPG and subtitle data there is no code for reading service names with ISDB character coding. DVBViewer doesn't recognize them as such and handles them like DVB service names, which yields garbage results.

 

I could insert code from TransEdit that would do the job. But there is another difficulty, caused by different kinds of ISDB character coding: The one used in Japan and the one used in Latin America (GS_LATIN_EXTENSION = ISO/IEC 8859-15, latin alphabet 9). I don't know if there are even more... anyway, for determining which one must be applied, DVBViewer needs language information. ISO language codes are usually available as part of EPG and subtitle data (e.g. "jpn" or "por" for Brazil), but unfortunately not in the Service Descriptor that contains the service name. How to solve that? I see two possibilities:

  • Use GetUserDefaultLCID for finding out if the PC is configured for Japanese language (true if the result is 0x0411).
  • Let the user configure it.

Now it's your turn to inform me about the details of your usage scenario and what would be appropriate under the given circumstances...

 

On 11/9/2021 at 10:05 AM, tim copperfield said:

I wish I was warned about the loss of my work before DVBViewer crashed.

 

What do you want? A countdown window popping up: "Please save your work. DVBViewer will crash in 10, 9, 8.... seconds!". A nice idea :)

 

Usually DVBViewer doesn't crash, which raises the question: What makes it crash in your case? This should be investigated before other users get molested by unnecessary warnings. Are you still using your TBS 6983? Including TbsCIapi.dll? This is a known source of instability. So I would strongly recommend to not play TV/radio while you are editing your channel list....

 

Link to comment
5 hours ago, Griga said:

AFAIK ISDB service names are not Unicode. ISDB is using specific character sets with names like GS_KANJI, GS_HIRAGANA, GS_KATAKANA, GS_LATIN_EXTENSION etc. However, DVBViewer converts them to UTF-8. This at least applies to EPG data and ISDB subtitles.

ISDB-T in Japan is the ARIB STD-B24-defined character set which is kinda ISO2022JP but worse. The service names are also using this encoding, yes.

5 hours ago, Griga said:

Wrong. DVBViewer uses the Windows API to convert channel names to the local character set. On a PC configured for Japanese locale this would be SHIFTJIS_CHARSET (code page 932). Would this cover your needs?

There's also another, actually correct option: The application is internally in Unicode and does NOT depend on whatever current "codepage" is. Since Unicode data files are annoying (not really, but I can see where it can be for a customer base of mostly US-ASCII/ISO8859-1 users), UTF8 is a perfectly viable option that doesn't break "existing software" ( = stuff that treats everything as ASCII or iso-latin)

5 hours ago, Griga said:

However, a code research revealed, that in contrast to EPG and subtitle data there is no code for reading service names with ISDB character coding. DVBViewer doesn't recognize them as such and handles them like DVB service names, which yields garbage results.

That's exactly what I'm experiencing, however, even if it did do the conversion, the resulting saved file would still be garbage as it would end up as ???'s.

5 hours ago, Griga said:

I could insert code from TransEdit that would do the job. But there is another difficulty, caused by different kinds of ISDB character coding: The one used in Japan and the one used in Latin America (GS_LATIN_EXTENSION = ISO/IEC 8859-15, latin alphabet 9). I don't know if there are even more... anyway, for determining which one must be applied, DVBViewer needs language information.

Since ISDB-T is a fucked up standard that should have never left Japan, any non-Japanese extensions to it are simply hacked on completely disregarding any existing DVB rules or recommendations. One good example is the TOT/TDT table, which is mandated to be broadcast in JST instead of UTC, and there's no indication of timezone since the standard doesn't provide for it. You just have to assume that if you're in Japan, and receiving ISDB-T, the times are JST, and not UTC. The same applies to EPG as well.

You could use language codes (yes, it does use jpn) to autodetect (but what about a French movie channel playing a Japanese movie with a french dub on one pid and japanese original audio on another), you could also check for presence of BAT/BIT/etc tables, you could also have a global setting that enables ISDB-specific hacks, etc. tsduck (ts parsing/analyzing toolkit) has a --japan option which enables all the hacky stuff, and after implementing that, had to add a --brazil option because more hacks were needed there which weren't compatible to Japan.

 

Basically, properly handling ISDB requires a per-country setting which can (*sometimes) be autodetected with some degree of certainty, but is easier to allow user to select.

5 hours ago, Griga said:

However, DVBViewer converts them to UTF-8

If you're already doing this why are we still arguing in other threads about saving channel/epg/etc data as some "locale setting" instead of literally just saving utf8 to disk as-is?!

 

5 hours ago, Griga said:

How to solve that? I see two possibilities:

  • Use GetUserDefaultLCID for finding out if the PC is configured for Japanese language (true if the result is 0x0411).
  • Let the user configure it.

 

All Windows versions since 2000 were Unicode-enabled and locale stuff is leftover of MBCS/non-unicode jank from Win95/98/ME. If the app does everything internally in Unicode, none of these problems exist. As I said earlier, utf8 is a good middle ground for data interchange as it takes up same amount of space as ASCII does for majority of the use cases.

5 hours ago, Griga said:

Are you still using your TBS 6983? Including TbsCIapi.dll?

I'm not sure what TBSClapi.dll is, but I'm not using that. I just have the normal TBS driver. The card itself has been stable.

Link to comment
20 hours ago, tim copperfield said:

UTF8 is a perfectly viable option that doesn't break "existing software" ( = stuff that treats everything as ASCII or iso-latin)

 

Regarding DVBViewer, you don't know what you are talking about.

 

DVBViewer is an application with a long history, that began in 2002. The development environment is still Delphi 7, that was also published in 2002 (Windows XP times if you remember...). The Delphi 7 VCL (Visual Component Library) is not capable of Unicode, but works with local character code pages throughout. For being able to display Unicode, some of the VCL components in DVBViewer (e.g. in the EPG window) have been replaced by Unicode compatible third party components, but only where needed.

 

Now, what happens if I let DVBViewer convert all channel names to UTF-8 when loading the channel list? I've just tried... it looks good at first sight, no issues in the Channel Editor and various Channel List representations. However, when I open the favourites sub-menu of the DVBViewer main menu or context menu, I see that all German umlauts (äöüÄÖÜ) in channel names are garbled, because the menu is a VCL component. It could be replaced by a Unicode compatible menu, but after that all language file entries for the menu have to be converted to Unicode, because the language files are using the local code pages. Additionally certain general menu modifications performed by DVBViewer have to be doubled, because they have to be applied to two different kinds of menu components, except if I would replace all (quite a lot) menus in DVBViewer by Unicode compatible menus... and that's just the tip of the iceberg, without examination of side effects on the DVBViewer Media Server, on TransEdit, on Add-Ons that are still used, but not maintained by their developers anymore...

 

Link to comment

In the next days a DVBViewer version with optional support for UTF-8 channel names will probably be available. I've spent some days with coding the necessary changes and could solve most (but not all) problems. Would you like to beta-test it?

 

Link to comment
1 hour ago, Griga said:

In the next days a DVBViewer version with optional support for UTF-8 channel names will probably be available. I've spent some days with coding the necessary changes and could solve most (but not all) problems. Would you like to beta-test it?

Hey,

 

Yeah absolutely.

That would be great!

Link to comment

Thanks for the updated build. I installed it and enabled the following options:
broadcast standard: 2 (isdb japan)

save as unicode: on

 

So far everything looks ok (including the changes to renaming/clicking/etc, very nice).

Renaming  channels persists across the save, and looks fine in UI except in one place:image.png.c2d597de64984e24292f674e5daac19a.png

The text after 57, if channel name is in Japanese, displays as blank.

Here's an example where channel hasn't been renamed:

image.png.143c7b8de633a25f33ed6c6e42cf065e.png

 

The rest of the channel editor stuff seems to be OK as far as I can tell.

However, scanning a frequency still results in same mess as before:

image.png.cc69d55c10e3798a4623083fa2a82d1e.png

I just scanned one transponder to save time.

The channels should be something like BBCワールド or etc.

I can provide some .ts files of this if you want to debug (or likely its just something you missed in the broadcast system settings?

Link to comment
5 hours ago, tim copperfield said:

The text after 57, if channel name is in Japanese, displays as blank.

 

Strange. Here it works under Windows 8.1 and Windows 10:

 

grafik.png

 

Maybe the font doesn't provide the characters on your PC? The OSD skin files indicate that Segoe UI Light is used for the channel name (see "C:\Program Files (x86)\DVBViewer\OSDSkins\Default\myMiniEPG.xml" -> #channelname definition and "C:\Program Files (x86)\DVBViewer\OSDSkins\Default\font.xml" -> DefaultFont definition.

 

Please post the characters that are expected to appear in the OSD, so I can copy them.

 

5 hours ago, tim copperfield said:

However, scanning a frequency still results in same mess as before

 

Confirmed. There was still a bug. Fixed in another test version (see PM)

 

Link to comment
16 hours ago, Griga said:

Confirmed. There was still a bug. Fixed in another test version (see PM)

Confirmed fixed.

Scan looks proper now.

 

What exactly does the broadcast standard = 2 change?

Because now I am not getting any EPG (on normal, EIT p/f + EIT long term) channels.

In ISDB, all EIT data is transmitted in JST.

I think there's some time offset being somewhere so that 'current epg' doesn't appear.

16 hours ago, Griga said:

Maybe the font doesn't provide the characters on your PC?

Of course it does, besides, doesn't windows automatically substitute fonts when its missing characters?

Anyway, the OTHER stuff shows correctly.

I changed DefaultFont to Arial Unicode MS, I can confirm different font in the UI, but the channel name is still blank:

image.png.a0660349a05edd31da49cdedab2c61ca.png

I think the issue is somewhere else.

Link to comment
4 hours ago, tim copperfield said:

What exactly does the broadcast standard = 2 change?

  1. Force DVBViewer to regard strings as ISDB strings, even if they don't start with an ISDB specific control code [0x0E,0x0F,0x19,0x1B,0x1D] (which is a way to distinguish them from DVB strings that are using other control codes for character set indication).
  2. Force DVBViewer to regard strings as Japanese, even if there is no 'jpn' ISO language code.

if (Language = 'jpn') or (BroadcastStandard = 2) then...

 

I think it would be good if you would use the TransEdit Analyzer for getting insight in the broadcasted Service Information (SI) tables. Download TransEdit from the customer area, have a look at the included ReadMe, launch TransEdit, select the transponder list for your satellite position on the left side of the main window, the frequency in question on the right side, and click "Analyze". More about the Analyzer and SI tables here. Please note that you can select the broadcast standard that TransEdit shall assume on Settings -> General in the same way as for DVBViewer.

 

Additionally it would be good if you could provide a transponder dump (1 minute or so). You can record it with the Analyzer: Right click the PID list -> Select All, then click "Start Recording". The output directory can be viewed/selected on Settings -> Analyzer.

 

Maybe adjustments are necessary because it is ISDB-S. All my samples are ISDB-T.

 

4 hours ago, tim copperfield said:

the channel name is still blank

 

Again: Please post the channel name that is supposed to appear in the OSD, so I can copy & paste it.

 

Link to comment
On 11/22/2021 at 1:26 PM, Griga said:

Again: Please post the channel name that is supposed to appear in the OSD, so I can copy & paste it.

The channel name is custom-entered by the user (I mean, its editable in channel list). In my case it's exactly this:

Quote

449 カヴァーソング (JPOP)

I've tried changing font and I can confirm that other text changes, but the title is still blank ONLY when it has non-ascii text in it.

 

I know about SI tables, I have written both SI parser and generator for ISDB-related services, so I know what's going on there.

I will capture and provide some sample TS but since this is a text that can come from satellite OR be entered manually by user, I think you can just copy paste it to test the behavior there... 

 

By the way, I just checked, and if the channel name has *any* non-ascii characters, it immediately becomes blank.

I took the "J SPORTS 2" from the earlier screenshot (notice it has japanese double-wide space, not ascii space) and replaced it with "J SPORTS 2" (ascii space), and on refreshing the program view, it was drawn. Since it ONLY affects service name but no other display, I still think its something code-related:

image.png.237e04319d15fe0bd77ca4ec896fc1e6.png

After add ascii space ^

Before add ascii space v

image.png.6d64d94e97b7102dcab1c8a0734e7310.png
 

Link to comment
On 11/22/2021 at 1:26 PM, Griga said:
  • Force DVBViewer to regard strings as ISDB strings, even if they don't start with an ISDB specific control code [0x0E,0x0F,0x19,0x1B,0x1D] (which is a way to distinguish them from DVB strings that are using other control codes for character set indication).
  • Force DVBViewer to regard strings as Japanese, even if there is no 'jpn' ISO language code.

My point with 

 

On 11/22/2021 at 8:47 AM, tim copperfield said:

In ISDB, all EIT data is transmitted in JST.

this was that, if you set broadcast to 2 (japan), all incoming EPG from terrestrial/satellite/cable sources should assume that EIT p/f + schedule as well as TOT/TDT is transmitted in JST (GMT +9), ignoring any use specified offset.

 

Right now if I do this,

image.png.3ca00b5e9b4d197d6b4c4919e63a3c69.png

Does this work? Should I leave it on automatic in case of broadcast=2 and hope DVBViewer will do the right thing?

Link to comment
vor 9 Stunden schrieb tim copperfield:

In my case it's exactly this:

 

No problem here. I renamed a channel to カヴァーソング (JPOP), and DVBViewer displayed it happily in the OSD.

 

vor 9 Stunden schrieb tim copperfield:

Since it ONLY affects service name but no other display, I still think its something code-related

 

The code is straight forward. In converts the UTF-8 channel name to UTF-16 (Delphi WideString, Windows LPWSTR) and assigns it to the channel name label.

 

However, when looking dreamily at this

 

grafik.png

 

something attracted my attention. As you can see, the Japanese characters are a bit higher than the Latin characters. So I started to play with the

 

    <height>24</height>

 

element of the DefaultFont definition in font.xml, changed it to 36, 40, 48 and finally reached a state where a text with Latin characters only was still displayed (though being far too high for fitting into the label), but not if it contained Japanese characters. What does this tell us?

 

What are your Windows text size settings? Mine are 100% for a full HD monitor.

 

What happens if you decrease the DefaultFont height in font.xml?

 

vor 9 Stunden schrieb tim copperfield:

Does this work? Should I leave it on automatic in case of broadcast=2 and hope DVBViewer will do the right thing?

 

"Automatic" simply means that DVBViewer queries Windows for the current time zone (which includes automatic adaptation to daylight saving time and back). The configured broadcast standard does not affect the time zone setting whatsoever. I've only introduced it for informing DVBViewer about the correct string handling (either for ISDB Japan or ISDB Latin America).

 

EPG showing up with BroadcastStandard=0, but not with BroadcastStandard=2 suggests that the strings do not conform to the DVBViewer handling of ISDB strings. No problem here with the EPG strings in my ISDB-T samples, though. This is the result of a live simulation with one of my samples and BroadcastStandard = 2:

 

grafik.png

 

Link to comment
11 hours ago, Griga said:

What are your Windows text size settings? Mine are 100% for a full HD monitor.

 

What happens if you decrease the DefaultFont height in font.xml?

4K @ 125% scaling.

Decreased height to 20 in DefaultFont and it renders correctly:

image.png.a76fdda9eedf2eaae5bfec9f0f8eba54.png

Odd, to say the least.

 

On to the EPG:

I'll re-test again with broadcast standard cleared.

 

Meanwhile, here's the BBC world mux with some EPG, and the radio (but I don't expect anything interesting to be there, just FYI)

https://drive.google.com/file/d/1saJjU4fgkVNjWCCGmsSmcQSaM7cA0Fy4/view?usp=sharing world

https://drive.google.com/file/d/13-m1HroxoE5fwGJ_7osFvY4vyzwy7Tt3/view?usp=sharing radio

 

Link to comment
12 hours ago, Griga said:

I've only introduced it for informing DVBViewer about the correct string handling (either for ISDB Japan or ISDB Latin America).

OK, so one more thing you'll need to add when standard=2 (for ISDB-*) is that EIT/TOT are transmitted in JST not UTC and adjust the source times accordingly.

I'm sure DVBViewer stores the EPG data in UTC.

Link to comment
vor 9 Stunden schrieb tim copperfield:

4K @ 125% scaling. Decreased height to 20 in DefaultFont and it renders correctly. Odd, to say the least. 

 

Some time ago I had a short look at the OSD text rendering code and hoped that I would never have to deal with it ;) It's using GDI+, specifically Graphics.DrawString. The issue is caused by text being too large for the specified layoutRect. I can reproduce it with a Windows text size of 125%.

 

It is clear that OSD text must not be influenced by the Windows text size setting, because the OSD is scaled to the video area size. As compensation for a Windows text size greater than 100%, DVBViewer scales the font size down accordingly, in your case to 24 / 1.25 = 19.2, which is ok so far, because  GDI+ is able to process floating point sizes.

 

When it comes to displaying the text, DVBViewer tries to calculate a fitting layoutRectangle with integer boundaries. Among other things it uses something like Height := Round(Font.GetHeight(Graphics)) for it. However, the GetHeight result is not 19.2, but GDI+ performs some confusing calculations in between (see here). Anyway, the floating point result may become less after rounding has been applied. That's how the bounding rectangle can get too small, and that's why some font height values work and others don't for Japanese "full height" characters, depending on whether the GetHeight result is rounded up or down.

 

After replacing the DVBViewer rounding by Height := Ceil(Font.GetHeight(Graphics)) the issue seems to be gone. I can't find font height values anymore that let Japanese text vanish. But actually I don't really know what I'm doing there. I hope it's a good guess...

 

vor 11 Stunden schrieb tim copperfield:

OK, so one more thing you'll need to add when standard=2 (for ISDB-*) is that EIT/TOT are transmitted in JST not UTC and adjust the source times accordingly.

 

I see. JST is a time zone. Japanese Standard Time = UTC + 9, correct? After

 

Am 22.11.2021 um 00:47 schrieb tim copperfield:

In ISDB, all EIT data is transmitted in JST.

 

I suspected that it is another bloody ISDB character set ;)

 

vor 11 Stunden schrieb tim copperfield:

I'm sure DVBViewer stores the EPG data in UTC.

 

Unfortunately it doesn't. But it expects all EPG start times to be UTC and adds the local time zone offset before storing them. So in your case everything should be fine if you set manual time zone to 0. Please check it.

 

Link to comment
31 minutes ago, Griga said:

Japanese Standard Time = UTC + 9, correct?

Yep, right

31 minutes ago, Griga said:

I suspected that it is another bloody ISDB character set

haha

31 minutes ago, Griga said:

Unfortunately it doesn't. But it expects all EPG start times to be UTC and adds the local time zone offset before storing them. So in your case everything should be fine if you set manual time zone to 0. Please check it.

Yep, that fixes it.

I can see EPG at correct time now.

So how do you think it should be handled? properly handle it with EPG timezone = Auto (by adjustting UTC +9 when broadcast standard = 2) and let the user screw themselves when it's manual (but also work when setting offset to zero)?

 

Link to comment
33 minutes ago, Griga said:

After replacing the DVBViewer rounding by Height := Ceil(Font.GetHeight(Graphics)) the issue seems to be gone. I can't find font height values anymore that let Japanese text vanish. But actually I don't really know what I'm doing there. I hope it's a good guess...

Good news, well, i'll test/look at it whenever you got a new test version ready later on. For now, reducing the font size fixed the display for me (keeping segoe ui)

Link to comment
vor 19 Stunden schrieb tim copperfield:

So how do you think it should be handled?

 

With care :) because changes may also side-affect EPG import/export APIs, timer recordings and other stuff in DVBViewer and the Media Server. It will take a bit of time to investigate all this. Basically the function that queries Windows for the (automatic) time zone offset should return 0 if the broadcast standard is ISDB Japan, provided the result is applied to broadcasted EPG start times and not to something else.

 

I wonder how EPG times are handled in the Latin American ISDB version. There are 4 time zones in Brazil.

 

vor 19 Stunden schrieb tim copperfield:

For now, reducing the font size fixed the display for me (keeping segoe ui)

 

Other parts of the OSD may be affected as well, e.g. channel list or EPG pages. Up to now I've found no time to check it all... maybe you can have a look at it (press ESC for opening the OSD main menu). I've uploaded a DVBViewer version with the OSD fix (see PM).

 

Link to comment
4 hours ago, Griga said:

maybe you can have a look at it

Sounds good, grabbed and will test tomorrow...

edit: checked out all the places (channel list, program, 'now playing', 'whats now', so on) and everything looks to be displaying correctly.

Edited by tim copperfield
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...